后端接口Api和管理（后端API）

本篇文章给大家谈谈后端接口Api和管理，以及后端API对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享后端接口Api和管理的知识，其中也会对后端API进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、六大接口管理平台，总有一款适合你的！
• 2、如何处理好前后端分离的 API 问题
• 3、瞧瞧人家用SpringBoot写的后端API接口，那叫一个优雅

六大接口管理平台，总有一款适合你的！

先聊一聊前端和后端分离后端接口Api和管理的优点。前后端分离优点如下：

其中不可避免的就是定制好接口文档，后端工程师要写好单元测试，推荐使用 chrome 的插件 postman 或 soapui或 jmeter，service 层的测试用例拿 junit 写。
但是这种情况对于接口文档管理很不方便，所以下面就罗列一些互联网公司常用的接口文档管理平台。

Swagger是一个大型的API开发者的工具框架，该框架提出后端接口Api和管理了一个编写OpenAPI的规范（命名为OAS），并且Swagger可以跨整个API生命周期进行开发，从设计和文档到测试和部署。
Swagger框架三核心：

YApi部署流程介绍

YApi 是高效、易用、功能强大的 api 管理平台，旨在为开发、产品、测试人员提供更优雅的接口管理服务。它可以帮助开发者轻松创建、发布、以及维护API。除此之外，YApi 还为用户提供后端接口Api和管理了优秀的交互体验，开发人员只需利用平台提供的接口数据写入工具以及简单的点击操作就可以实现接口的管理。特性:

难点：如果需要要执行自动化测试，需要编写脚本。

Eolinker是国内企业级IT研发管理解决方案服务品牌，在线API接口管理服务供应商，致力于满足各行业客户在不同应用环境中对研发管理全生命周期的个性化需求，提供API开发管理（AMS）、开发团队协作、自动化测试、网关（AGW）以及监控（AMT）等服务。
特性：

ShowDoc一个非常适合IT团队的在线API文档、技术文档工具。
随着移动互联网的发展，BaaS（后端即服务）越来越流行。服务端提供API，APP端或者网页前端便可方便调用数据。用ShowDoc可以非常方便快速地编写出美观的API文档。

项目地址： https://www.showdoc.cc

DOClever是一个可视化接口管理工具 ,可以分析接口结构，校验接口正确性， 围绕接口定义文档，通过一系列自动化工具提升我们的协作效率。
特性：

DOClever官网： http://www.doclever.cn/controller/index/index.html
DOClever GitHub： https://github.com/sx1989827/DOClever

阿里妈妈前端团队出品的开源接口管理工具RAP第二代，RAP通过GUI工具帮助WEB工程师更高效的管理接口文档，同时通过分析接口结构自动生成Mock数据、校验真实接口的正确性，使接口文档成为开发流程中的强依赖。有了结构化的API数据，RAP可以做的更多，而我们可以避免更多重复劳动。基于RAML的接口定义、文档生成、Mock Server完成了定义和使用的分离，通过一套规范完成的接口定义，可以用不同的工具得到适应不同API管理系统的输出，有更多的可能性，同时保持了核心定义不变。RAP较之于RAML，前者更加集中，所有的定义、文档、mock都在同一个服务中完成，并且实时生效，方便快捷，如果只考虑方便易用，RAP是更好的选择，而RAML显得更加繁琐，更适合于公开的接口定义，方便在各个系统之间流转。

github源码地址： https://github.com/thx/rap2-delos

如何处理好前后端分离的 API 问题

意义很大，但是你的问题本身认识有偏差。
对于前后端分离，认识上有个误区，那就是很多人自称：老早就分离了，全AJAX，使用Angular或者什么什么就可以了。
这个说法是不合适的，打个比方，别人问的是“如何解决家禽把蛋生在水草边的问题？”，但实际上人家养的是鸭子，答题的却是养鸡的，所以回答“不让去水边就行了”，这显然不在点子上。
这两年业界说的前后端分离，是限于偏展示类的系统（用A代替），而不是应用、管控类Web项目（用B代替），在B类项目里，前后端是天然分离的，对此，除了少部分后端开发人员，基本所有人的认识都是一致的。上一段中这样回答的人一般都是只做B类项目，在B类项目里，前后端分离是共识，不需要讨论。
那么，剩下的问题就是讨论A类项目的前后端分离了。这个问题的核心在什么地方呢，在于模板的与数据结合的位置，以及，模板的控制权在谁手里。经过这两年的讨论，基本上我们可以达成的共识就是：模板应当由前端人员去控制，主要原因有两方面：
- 性能优化（尤其是外部资源的管理与发布，请求合并等等）
- 协作的顺畅性（已形成模板的界面片段的返工等问题）
那么，模板到底应该在什么地方跟数据结合？
这个问题就比较折腾了，有部分人尝试像B类项目那样，使用js模板，然后在浏览器端执行，这是存在一些问题的，比如说seo不友好，首屏性能不够，尤其对于首页DOM量很大的电商类网站，差距很明显。
所以还是得把主要的模板放在服务端来执行。在这个过程中，阿里作了一些尝试，那就是引入Node层，在这一层把模板与数据进行合成，然后浏览器拿到的就是生成好的HTML了，但也不是所有HTML都是这么生成好的，还是会有一些内容等到了浏览器之后，再用js去加载和生成。

瞧瞧人家用SpringBoot写的后端API接口，那叫一个优雅

假设实现一个注册用户的功能，在controller 层，他会先进行校验参数，如下：

以上代码有什么问题嘛？ 其实没什么问题，就是校验有点辣眼睛 。正常的添加用户业务还没写，参数校验就一大堆啦。假设后来，又接了一个需求：编辑用户信息。实现编辑用户信息前，也是先校验信息，如下：

我们可以使用注解的方式，来进行参数校验，这样代码更加简洁，也方便统一管理。实际上， spring boot 有个 validation 的组件，我们可以拿来即用。引入这个包即可：

引入包后，参数校验就非常简洁啦，如下：

然后在 UserParam 参数对象中，加入 @Validated 注解哈，把错误信息接收到 BindingResult 对象，代码如下：

如果你在你们项目代码中，看到controller 层报文返回结果，有这样的：

也有这样的：

显然，如果接口返回结果不统一，前端处理就不方便，我们代码也不好维护。再比如有的人喜欢用 Result 处理结果， 有点人 喜欢用 Response 处理结果，可以想象一下，这些代码有多乱。

所以作为后端开发，我们项目的响应结果，需要 统一标准的返回格式 。一般一个标准的响应报文对象，都有哪些属性呢？

响应状态码一般用枚举表示哈：

因为返回的数据类型不是确定的，我们可以使用泛型，如下：

有了统一的响应体，我们就可以优化一下controller 层的代码啦：

日常开发中，我们一般都是自定义统一的异常类，如下：

在controller 层，很可能会有类似代码：

这块代码，没什么问题哈，但是如果 try...catch 太多，不是很优雅。

可以借助注解 @RestControllerAdvice ，让代码更优雅。 @RestControllerAdvice 是一个应用于 Controller 层的切面注解，它一般配合 @ExceptionHandler 注解一起使用，作为项目的全局异常处理。我们来看下demo代码哈。

还是原来的 UserController ，和一个会抛出异常的userService的方法，如下：

我们再定义一个全局异常处理器，用 @RestControllerAdvice 注解，如下：

我们有想要拦截的异常类型，比如想拦截 BizException 类型，就新增一个方法，使用 @ExceptionHandler 注解修饰，如下：

关于后端接口Api和管理和后端API的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 后端接口Api和管理的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于后端API、后端接口Api和管理的信息别忘了在本站进行查找喔。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。