swagger

基于上一篇 其实只是在SwaggerConfig.class中配置docket，apiInfo @Configuration // 变成配置文件 @EnableSwagger2 // 开启swagger2 public class SwaggerConfig { @Bean // 配置swagger的docket的bean实例 public Docket docket(){ return new Docket(DocumentationType.SWAGGER_2) .apiInfo(apiInfo()); } // 配置swagger信息的ApiInfo private ApiInfo apiInfo(){ // 作者的联系方式 Contact contact = new Contact("xiaowei","https://www.baidu.com","1102356056@qq.com" ); return new ApiInfo( "xiaowei hello" , "有一种想见不敢见的伤痛 有一种爱还埋藏在我心中" , "v0.1" , "ttps://www.baidu.com" , contact, "Apache 2.0" , "http://www.apache.org/licenses/LICENSE-2.0" , new ArrayList() ); } }

随着微服务的越来越流行，越来的越多的公司开始实行微服务架构，相对于单一应用架构，微服务将复杂性拆分并且打散到一个个粒度更加细分的应用中，极大了减少了开发中单个服务的复杂性，开发人员只需要面向专注单一业务场景编程，从技术开发角度，单一服务代码量上减少很多，从业务角度上，业务复杂性的降低降低了需求的沟通成本，然而，整体业务复杂性依然存在，当我们需要接入或者依赖其他服务时，通常作为接入方来说，我们不需要深入了解服务提供方的业务，此时API成为了开发人员间的沟通语言。良好的API设计，能极大的减少沟通成本，甚至有时候可以代替文档，尤其是对于基础性服务来说，服务的可扩展性有时候体现在API的可扩展性，我曾经参与过一个基础业务微服务的业务升级，由于旧版本的API划分不够清晰，部分API存在重复性，后面不得不对大部分API进行重构（替换为新版本的API），仅仅在服务消费方升级这个阶段就持续1-2个月之久，在这个过程中也不断对API设计中存在的一些问题以及应该遵循哪些原则进行了一些思考。 API先行 在敏捷开发的大浪潮下，产品上通常要求快速迭代，面对一个新的需求，如果需要开发新的接口，通常在表结构完成设计后，开发人员就需要完成API设计并交付消费方（即服务的调用方或者依赖方，文中其余部分均表示此含义），在技术联调前，消费方可以Mock接口来完成调试。所以通常来说，API先与服务交付，之后再完成编码