开发 - 简谈前后端分离应用模式
前后端分离介绍
1、web 开发方式：前后端分离
在前后端分离的应用模式中，后端仅返回前端所需的数据，不再渲染 HTML 页面，不再控制前端的页面的跳转。
至于前端用户看到什么效果，从后端请求的数据如何加载到前端中，这些都是由前端自己决定，网页有网页的处理方式，App 有 App 的处理方式，但无论哪种前端，所需的数据基本相同，后端仅需开发一套逻辑对外提供数据即可。
在前后端分离的应用模式中，前端与后端的耦合度相对较低。
在前后端分离的应用模式中，我们通常将后端开发的每个视图都称为一个接口或者 API ，前端通过访问接口来对数据进行增删改查，后端返回给前端的数据格式主要为：json 格式。
以下为数据交互图：
2、API接口：Restful 风格
2.1、规范原则：
- 接口返回数据即显示：前端仅做渲染逻辑处理；
- 渲染逻辑禁止跨多个接口调用；
- 前端只需关注交互、渲染逻辑，要尽量避免逻辑处理的出现；
- 请求响应传输数据格式：JSON, json格式应尽量简单轻量，避免多级 json 的出现；
2.2、HTTP URL:
格式规范：
- URL 中尽量使用小写字母；
- URL 中不适用连字符；
- URL 中不要包含文件(脚本)的扩展名；
- URL 中请求单个资源需要用单数命名；
- URL 中请求集合或者多个资源使用复数命名；
- CRUD的操作不要体现在URI中，HTTP协议中的操作符已经对CRUD做了映射；
HTTP URI模板如下：
http://{root-url}/api/{api-version}/{service-name}/{resource-name}/{action}
- service-name：必须，表示服务名称，如：flow、auth
- resource-name: 必须，请求的资源名称，如：staff、role
- action: 选填，对于某个资源的操作不是CRUD，此处填入进行的操作。如：binding、check
2.3、HTTP Method：
http方法应当支持下面几种方法：
-
GET 获取某个资源 ；
-
POST 新增某个资源，请求的格式应是json；
-
PUT 修改某个资源，请求的格式应是json
(PUT方法可用来更新一个资源的全部属性，使用时传递所有属性的值，即使有的值没有改变）
-
DELETE 删除某个资源；
-
PATCH：更新（Update），通常是部分更新；
2.4、接口示例：
接口名称：消息平台接收EDIT POOL的Opt状态查询接口
接口描述：该接口由消息平台提供，查询mds用户的OPT授权状态。
请求URL ：
http://localhost:9099/editpool/mdsstatuquery
请求方式：
POST
请求参数：
| 参数名称 | 参数含义 | 参数类型 | 备注 |
|---|---|---|---|
| userId | 用户ID | String | 用户的唯一id值，能够找到用户，如：“abc” |
| serviceOrder | 订单编号 | String | 如：SIFG0892801903011111 |
请求参数示例：
{
“userId”: “abc”,
“serviceOrder”:“SIFG0892801903011111”
}
返回参数：
| 参数名称 | 参数含义 | 参数类型 | 备注 |
|---|---|---|---|
| code | 调用的结果代码 | int | 调用成功，返回000000；调用失败，根据错误类型返回预定义的error code |
| status | 调用的结果，成功与否 | String | success/failure |
| msg | 如果调用失败，失败的原因 | String | |
| data | payload | Json | json格式 |
data:
| 参数名称 | 参数含义 | 参数类型 | 备注 |
|---|---|---|---|
| notificationType | 查询给出的状态 | String |
返回参数示例：
{
“data”: {
“notificationType”: “Opt-in”
}
“code”: “000000”,
“status”: “success”,
“msg”: “”
}
2.5、接口设计建议：
安全性：
外部接口应考虑采用HTTPS协议，以确保交互数据的传输安全。涉及到敏感数据时，应使用POST请求，而不是GET请求。
接口的版本：
根据业务的实际情况，当一个接口有不同版本的实现时，在URL中使用v{x}表明接口的版本信息。
Swagger：
Swagger可以方便的管理rest API的文档。