发布网友 发布时间:2024-09-26 15:35
共1个回答
热心网友 时间:26分钟前
我是这样使用SpringBoot(API传参)springboot中的Controller或者RestController接收参数的方法是一样的。这章目标是对几种常用的传参都写个例子。
创建package:com.biboheart.demos.api,这个包里放置API接口的RestController
在com.biboheart.demos.api包中创建一个class:ParamController。这章的示例都在这个类中进行。
路径中包含参数,这种情况适合与传递一个不能为空值的参数。比如有些应用中,查询某个企业的数据,必须包含企业的编号,就可以在地址里接收这个编号。
在ParamController中增加一个函数PathParam
路径中的参数通过{sn}接收值。
使用名称接收参数比较直观,我用得比较多。不用注解。跟客户端传的参数同名就可以接收到。如下例子中的reqParam
也可以用get传参
上面用参数名称接收值,只要与请求时的名称一致就能接收到参数值。如果需要传递的参数比较多的时候,就不适合一个一个参数写在函数里了,那样很不方便,也容易出错。可以把这些参数写到一个对象里接收。如下例子
创建一个package:com.biboheart.demos.model,创建一个类Person
用Person对象接收参数
虽然这样的方式也能接收get传参,但是因为需要传的参数多了,用get显得不太方便。这里就不测试GET方式请求了。
有的时候,需要接收JSON传参。比如某些服务的调用需要开发一个回调函数接收对方的回调并获得参数值为结果,对方回调回来的值是JSON格式的值,这时候就需要接收JSON传参数了。用RequestBody可以接收到JSON传值。
需要JSON请求才能正确接到值
SpringBoot实例:医院统一信息平台(apigateway)
前面已经在平台中使用了springcloud。每个小的服务中各自实现相关业务,提供API。这些服务的访问地址都可能不一样。这样给使用都造成困扰,而且服务器接口管理也复杂了。
api-gateway就是把这些api通过一个服务提供出去。在这个服务中代理其它服务的API。对于服务的使用都就像是访问一台服务器。
这里用springzuul实现api-gateway。
创建一个项目(服务),专门做api代理。服务名称huip-router。
pom
RouterApplication
为了支持跨域,增加一个Filter
配置
在API请求开头为/huipuser/时访问的是user服务的API,如果开头/huippatient/时访问的是patient服务的API。比如请求相当于
请求测试。
SpringBoot实例:医院统一信息平台(服务间通讯)的访问流程改成用代理。
基于SpringBoot的API测试互联网产品的测试策略现在很多都会存在API测试、轻量级GUI测试、轻量级单元测试等。API测试其实我们一开始想得最多的图形化工具应该是postman、jmeter等。如果使用最简单的get方法,还可以直接通过使用CURL命令(即命令行工具cURL)。
不管使用什么API测试工具,API测试的基本步骤大体一致:
1.准备测试数据
2.通过API测试工具,发起对被测API的request
3.验证返回结果的response
我们平时在工作中,接触得最多的是用JAVA框架Springboot框架开发的简单的RestfulAPI。
Springboot建议的目录结果如下:rootpackage结构-com.example.myproject
瞧瞧人家用SpringBoot写的后端API接口,那叫一个优雅假设实现一个注册用户的功能,在controller层,他会先进行校验参数,如下:
以上代码有什么问题嘛?其实没什么问题,就是校验有点辣眼睛。正常的添加用户业务还没写,参数校验就一大堆啦。假设后来,又接了一个需求:编辑用户信息。实现编辑用户信息前,也是先校验信息,如下:
我们可以使用注解的方式,来进行参数校验,这样代码更加简洁,也方便统一管理。实际上,springboot有个validation的组件,我们可以拿来即用。引入这个包即可:
引入包后,参数校验就非常简洁啦,如下:
然后在UserParam参数对象中,加入@Validated注解哈,把错误信息接收到BindingResult对象,代码如下:
如果你在你们项目代码中,看到controller层报文返回结果,有这样的:
也有这样的:
显然,如果接口返回结果不统一,前端处理就不方便,我们代码也不好维护。再比如有的人喜欢用Result处理结果,有点人喜欢用Response处理结果,可以想象一下,这些代码有多乱。
所以作为后端开发,我们项目的响应结果,需要统一标准的返回格式。一般一个标准的响应报文对象,都有哪些属性呢?
响应状态码一般用枚举表示哈:
因为返回的数据类型不是确定的,我们可以使用泛型,如下:
有了统一的响应体,我们就可以优化一下controller层的代码啦:
日常开发中,我们一般都是自定义统一的异常类,如下:
在controller层,很可能会有类似代码:
这块代码,没什么问题哈,但是如果try...catch太多,不是很优雅。
可以借助注解@RestControllerAdvice,让代码更优雅。@RestControllerAdvice是一个应用于Controller层的切面注解,它一般配合@ExceptionHandler注解一起使用,作为项目的全局异常处理。我们来看下demo代码哈。
还是原来的UserController,和一个会抛出异常的userService的方法,如下:
我们再定义一个全局异常处理器,用@RestControllerAdvice注解,如下:
我们有想要拦截的异常类型,比如想拦截BizException类型,就新增一个方法,使用@ExceptionHandler注解修饰,如下:
SpringBoot2基于Swagger2生成离线Api文档Github:
Gitee:
个人觉得旧版的配置简单许多,新版的配置按照官方demo的配置来做还是复杂了很多
配置到Springboot项目中以后,在项目打包的时候便会通过单元测试在指定的目录生成被官方称为staticdocs的离线文档
该篇博文引用的依赖都要引入,SpringRestDocs的依赖spring-restdocs-mockmvc,离线文档的依赖springfox-staticdocs,因为要在单元测试的时候生成文档,所以需要再加测试相关的spring-boot-starter-test。
asciidoctor-maven-plugin插件会把Asciidoc格式文件转成HTML5格式输出。
这个类包含两个方法,TestApi()是用来生成例子,test()用来生成Asciidoc的文档。生成例子用到了spring-restdocs-mockmvc,每一个API都要进行单元测试才能生成相应的文档片段(snippets),生成的结果如图:
生成完整的Asciidoc文档用到了Swagger2MarkupConverter,第一步先获取在线版本的文档并保存到文件swagger.json中,第二步把swagger.json和之前的例子snippets整合并保存为Asciidoc格式的完整文档。生成结果如图:
通过配置类定义一些文档相关的信息
路径:项目名/docs/asciidoc/index.adoc
利用前面配置的maven插件,只需要执行打包就可以生成相应的文档,如图:
该篇博文引用的依赖都要引入,SpringRestDocs的依赖spring-restdocs-mockmvc,离线文档的依赖springfox-staticdocs,因为要在单元测试的时候生成文档,所以需要再加测试相关的spring-boot-starter-test。
asciidoctor-maven-plugin插件会把Asciidoc格式文件转成HTML5格式输出。
这个类包含两个方法,TestApi()是用来生成例子,createSpringfoxSwaggerJson()用来生成Asciidoc的文档。生成例子用到了spring-restdocs-mockmvc,每一个API都要进行单元测试才能生成相应的文档片段(snippets),生成的结果如图:
生成完整的Asciidoc文档用到了Swagger2MarkupConverter,第一步先获取在线版本的文档并保存到文件swagger.json中,第二步把swagger.json和之前的例子snippets整合并保存为Asciidoc格式的完整文档。生成结果如图:
通过配置类定义一些文档相关的信息
在resources目录下创建一个名为logback.xml的配置文件,使用LogstashEncoder作为DefaultLogEncoder
路径:项目名src/docs/asciidoc/index.adoc
利用前面配置的maven插件,只需要执行打包就可以生成相应的文档,如图: