实现API接口对接的几种方法
前端开发
浏览：827 次
在当今的移动互联网中，分布式和微服务非常流行。现在大多数项目都使用微服务框架，它将前端和后端分开， （题外话：前端和后端的责任越来越明确。现在前端被称为大前端，技术堆栈和生态系统已经非常成熟。过去，后端人员看不起前端人员，所以现在后端人员需要重新理解前端。前端已经变得非常系统。）自动）。
通用系统的总体架构如下：
需要注意的是，一些小伙伴会回答说，这种架构太简单，太低。没有网关、缓存或消息中间件。由于老顾的文章主要介绍API接口，我们将重点介绍其他模块，并自行添加。
界面交互
前端与后端相互作用。前端根据合同请求URL路径并传递相关参数。后端服务器接收请求，进行业务处理，并将数据返回到前端。
对于URL路径的restful风格和传入参数（如app_version、api_version和device等）的公共请求头的要求，Gu先生不会在这里介绍它们。年轻朋友很容易理解。
老顾重点介绍了后端服务器如何将数据返回到前端？
返回格式
后端返回JSON正文中的前端，定义如下：
＜pre＞｛#返回状态代码：integer，#返回信息描述消息：string，#返回值数据：object｝</pre＞
CODE状态代码
Code返回状态代码。通常，合作伙伴在开发过程中添加他们需要的任何内容。
如果界面需要返回用户权限异常，那么我们添加一个状态代码101。下次我们需要添加数据参数异常时，我们添加状态代码102。虽然服务可以照常满足，但状态代码太乱了
我们应该参考HTTP请求返回的状态代码
：以下是常见的HTTP状态代码：200-请求成功301-资源（网页等）被永久传输到其他URL 404-请求的资源（网页等等）不存在500-内部服务器错误</pre>
我们可以参考这种设计，它具有将错误类型分类到一定范围内的优点。如果范围不够，可以设计为4位数。
＜pre＞#1000～1999区间表示参数错误
2000~2999表示用户错误
3000～3999间隔表示接口异常
这样，在获得返回值后，前端开发人员可以根据状态代码了解错误，然后根据消息相关信息描述快速定位。
消息
这个字段比较容易理解，也就是说，当发生错误时，如何给出友好的提示。通常，它与代码状态代码一起设计，例如
然后在枚举中定义状态代码
状态代码和信息将一一对应，易于维护。
数据
返回数据体、JSON格式，并根据不同的业务返回不同的JSON体。
我们需要设计一个返回体类Result
控制层控制器
我们将在控制器层处理业务请求并将其返回到前端，以订单为例
我们可以看到，在获得order对象之后，我们使用Result构造方法包装和赋值，然后返回。你发现施工方法不是很麻烦吗？我们可以优化它。
美学优化
我们可以向Result类添加静态方法
让我们重建控制器
代码是否简洁美观。
优雅的优化
如上所述，静态方法已添加到Result类中，从而简化了业务处理代码。但您是否发现存在以下几个问题：
1.每个方法的返回都是一个结果封装的对象，它没有业务意义
2.在业务代码中，我们调用Result。成功时，调用Result。异常时发生故障。太多了吗
3.在上述代码中，我们可以判断ID是否为空。事实上，我们可以使用hibernate验证进行验证。无需在方法体中进行判断。
最好的方法是直接返回真实的业务对象，最好不要更改以前的业务方法，如下图所示
此代码与我们通常的代码相同。它非常直观，直接返回订单对象。这是完美的吗。实施计划是什么？
实施方案
你对如何实现它有什么想法吗？在这个过程中，我们需要做几件事
