swagger

5.5软件概要设计 　　概要设计，用于子系统或模块设计，也可用新增业务需求的跨子系统设计。概要设计在总体设计框架下，遵循总体设计思想，丰富子系统或模块设计，从而能够指导开发实现子系统或模块。 　　由于软件总体设计从宏观上架构软件，距离开发实现，还有许多需要细化之处。如果系统由多个子系统组成，每个子系统可以视为一个独立的应用软件或服务，此时概要设计不可省略；如果系统不大，重点模块也应需要做概要设计来细化。可以理解为概要设计粒度介于总体设计和详细设计之间。 　　另外，概要设计与代码实现的联系更紧密一些，如代码分层、核心的对象类及关系等。 　　 责任人 ：开发项目组长。 　　 执行人 ：高级程序员、子系统或模块开发人员。 　　 关键行为 ：分析和概要设计。　　 分析：根据子系统或模块的功能规划，结合对软件需求进行分析，完整把握需求； 概要设计：在总体设计框架下，完成子系统或模块的概要设计。 　　 输入 ： 软件需求规格书（SRS）； 数据字典（DD）； 用户故事集合； 其它需求资料； 软件总体设计文档。 　　 输出 ： 软件概要设计文档； 子系统结构设计； 功能模块设计； 接口设计； 软件结构设计； 数据库设计。 　　 职责要求 ： 概要设计； 沟通、协调、明确对接的上下游子系统/模块的接口和边界； 提请软件概要设计评审： 概要设计人员：主讲人，负责讲解和答复各种质询和疑问； 产品经理

一、配置IdentityServer4服务端 这里介绍两种方法 ①直接创建identityserver4的模板，在模板的基础上修改 ②创建新项目，自己搭建 第一种 参考 我的 identityServer4学习 ，创建一个identityServer4模板后 修改config文件 public static IEnumerable<IdentityResource> GetIdentityResources() { return new IdentityResource[] { new IdentityResources.OpenId(), new IdentityResources.Profile(), }; } /// <summary> /// API信息 /// </summary> /// <returns></returns> public static IEnumerable<ApiResource> GetApis() { return new [] { new ApiResource( " ProjectApiScope " , " Demo API with Swagger " ) }; } /// <summary> /// 客服端信息 /// </summary> /// <returns></returns> public static

问题起源 使用SpringCloud构建项目时，使用Swagger生成相应的接口文档是推荐的选项，Swagger能够提供页面访问，直接在网页上调试后端系统的接口， 非常方便。最近却遇到了一个有点困惑的问题，演示接口示例如下（原有功能接口带有业务实现逻辑，这里简化了接口）： /** * @description: 演示类 * @author: Huang Ying **/ @Api(tags = "演示类") @RestController @Slf4j public class DemoController { @ApiOperation(value = "测试接口") @ApiImplicitParams({ @ApiImplicitParam(name = "uid", value = "用户ID", paramType = "query", dataType = "Long") }) @RequestMapping(value = "/api/json/demo", method = RequestMethod.GET) public String auth(@RequestParam(value = "uid") Long uid) { System.out.println(uid); return "the uid: " + uid; } }

@ApiImplicitParam： 作用在方法上，表示单独的请求参数 参数： 1. name ：参数名。 2. value ： 参数的具体意义，作用。 3. required ： 参数是否必填。 4. dataType ：参数的数据类型。 5. paramType ：查询参数类型，这里有几种形式： 类型 作用 path 以地址的形式提交数据 query 直接跟参数完成自动映射赋值 body 以流的形式提交 仅支持POST header 参数在request headers 里边提交 form 以form表单的形式提交 仅支持POST 在这里我被坑过一次：当我发POST请求的时候，当时接受的整个参数，不论我用body还是query，后台都会报Body Missing错误。这个参数和SpringMvc中的@RequestBody冲突，索性我就去掉了paramType，对接口测试并没有影响。 @ApiImplicitParams： 用于方法，包含多个 @ApiImplicitParam： 例： @ApiOperation("查询测试") @GetMapping("select") //@ApiImplicitParam(name="name",value="用户名",dataType="String", paramType = "query") @ApiImplicitParams({

背景说明 近期在去面试的过程中，被问及有关WEB API的一些特性，一时竟不知该如何回答，故根据自己已知的知识，加上网上搜索的，详细列举了一下，期望对WEB API有一个比较开阔和全面的认知。 关键要素 在客户端发送一个请求，到服务端接收并处理请求，然后将数据返回，这样一个看似简单的过程中，究竟有哪些要素是我需要去留心的呢？ 我在整理的过程当中，发现了这样一些基本要素，是需要去特别留心： 1. 接口规范 2. 鉴权方式 3. 关键对象 4. 生命周期 5. 接口工具 接口规范 接口规范定义了在API访问的过程中，数据交互约定以什么样的方式进行。下面是我所了解的几种接口规范： 1.1.RESTful 1.1.1.字义解释 ▣ REST（representational state transfer），直译过来是“表述性状态传输”，至于ful，百度翻译是“满满的”、“充满...的”。这里所说的“state”，就是HTTP请求当中的 GET、PUT、POST 、DELETE，表述了对资源的处理意向。 1.1.2.规范详情 ▣ 参考 RESTful 架构详解 1.2.OpenAPI 1.2.1.字义解释 ▣ OpenAPI从字义上解释，是开放API，也就是说是开放给别人看的，所以接口参数具有可阅读性，能够生成可阅读的文档。它也具体到了业务层面的参数定义规范。 1.2.2.广义解释 ▣

项目地址 https://github.com/yinjihuan/kitty-cloud 前言 Kitty Cloud 开源后有以为朋友在 GitHub 上给我提了一个 issues，问为什么项目中要同时集成 Feign 和 Dubbo 两个框架来调用服务。今天就来聊一聊这个问题，然后讲下在 Kitty Cloud 中如何切换使用两种调用方式。 为什么要支持两种协议？ 关于支持两种协议，我这个是一个开源项目，主要还是为了让使用者有更多的选择。当然框架本身不是我开发的，我只是使用者而已。 一种协议更统一化，两种协议混着用也不是不可以，具体还是看实际需求。比如你们内部有个 ID 分发的服务，调用量很高，就是对性能有这极致的要求。那么这个场景你就可以用 Rpc 来代替 Http 了。其他的正常使用 Http 协议就行，特殊场景的就用 Rpc 协议，互补而已。 用 Http 最好的点在于简单，传输内容就是文本，调试什么的都很方便。比如我要单独测试某个服务的接口，直接 PostMan 上调用这个 Http 接口就可以了，或者用 Swagger。 如果是 Dubbo 的 Rpc, 我可能需要用 telnet 来调用。 还有就是网关层的转发，如果是 Http 协议，直接转发过去了。如果是 Rpc 协议，网关内部需要转特殊处理，当然目前也有支持 Rpc 的网关。如果我们是两种协议

前言 我们通常把 RPC 用作内部通信，而使用 Restful Api 进行外部通信。为了避免写两套应用，我们使用 grpc-gateway 把 gRPC 转成 HTTP 。服务接收到 HTTP 请求后， grpc-gateway 把它转成 gRPC 进行处理，然后以 JSON 形式返回数据。本篇代码以上篇为基础，最终转成的 Restful Api 支持 bearer token 验证、数据验证，并添加 swagger 文档。 gRPC转成HTTP 编写和编译proto 1.编写simple.proto syntax = "proto3"; package proto; import "github.com/mwitkow/go-proto-validators/validator.proto"; import "go-grpc-example/10-grpc-gateway/proto/google/api/annotations.proto"; message InnerMessage { // some_integer can only be in range (1, 100). int32 some_integer = 1 [(validator.field) = {int_gt: 0, int_lt: 100}]; // some_float can only be in

转发请注明此文章作者与路径，请尊重原著，违者必究。 本篇文章演示了使用Dockerfile在Linux（ubuntu16.04）系统上构建ASPNetCore应用，并且在一个解决方案中存在多个项目之间的引用。还会使用到私有Nuget包的引用。 构建项目 为了演示更加全面，这里按照简单的领域驱动模式建立了几个项目。 Web端为：TestWebDockerOnLinux。使用swagger对外提供API，并且包含了Dockerfile文件。 基础设施层：TestWebDockerOnLinux.Core。封装了基础实体类。 核心逻辑层：TestWebDockerOnLinux.Domain。封装了业务逻辑。 仓储层：TestWebDockerOnLinux.Repository。封装了对数据库的操作，使用仓储模式。 因为Web API层在TestWebDockerOnLinux，所以Dockerfile在此项目中。 项目构建都很简单，你自己可以构建两个项目，一个为Web，另外一个基础类库。为了演示对私有Nuget包的编译，我们在Web层上引用了以下的私有Nuget包并且引用了本地项目： 你可以按照系列（三）那样修改Dockerfile，但是这里演示不修改Dockerfile的路径，贴图： 下面详细说明： Dockerfile它是构建程序的配置文件，首先说明应用所依赖的环境，然后进行编译

首先，默认咱们已经有了.net core 3.1的开发环境，如果你没有，快去下载... https://dotnet.microsoft.com/download 由于项目是基于abp vNext开发的，所以开发之前建议去撸一遍abp官方文档， https://docs.abp.io/en/abp/latest/ 创建项目有很多种方式： 第一种，纯手撸，使用vs手动创建新项目 第二种，借助abp模板直接傻瓜式下载，地址： http://abp.io/get-started 第三种，abp cli(推荐) abp cli abp cli是使用ABP框架启动新解决方案的最快方法，那么前提是你要安装啊。 dotnet tool install -g Volo.Abp.Cli 如果你的版本比较低，使用下面命令进行更新 dotnet tool update -g Volo.Abp.Cli 更多使用方法，请参考 https://docs.abp.io/en/abp/latest/CLI abp new 终于进入主题了，使用命令 abp new <solution-name> 创建博客项目 默认会生成两个项目，一个aspnet-core，一个react-native。暂时干掉不需要项目吧，虽然react-native也很香，但是现在先忽略它。 然后将aspnet

前言 我们通常把 RPC 用作内部通信，而使用 Restful Api 进行外部通信。为了避免写两套应用，我们使用 grpc-gateway 把 gRPC 转成 HTTP 。服务接收到 HTTP 请求后， grpc-gateway 把它转成 gRPC 进行处理，然后以 JSON 形式返回数据。本篇代码以上篇为基础，最终转成的 Restful Api 支持 bearer token 验证、数据验证，并添加 swagger 文档。 gRPC转成HTTP 编写和编译proto 1.编写simple.proto syntax = "proto3"; package proto; import "github.com/mwitkow/go-proto-validators/validator.proto"; import "go-grpc-example/10-grpc-gateway/proto/google/api/annotations.proto"; message InnerMessage { // some_integer can only be in range (1, 100). int32 some_integer = 1 [(validator.field) = {int_gt: 0, int_lt: 100}]; // some_float can only be in