文章目录
- 一、web开发模式
- 1.1 前后端混合开发
- 1.2 前后端分离开发
- 二、API接口
- 2.1 简介
- 2.2 RESTful API接口规范
道阻且长,行则将至,行而不辍,未来可期🌟。人生是一条且漫长且充满荆棘的道路,一路上充斥着各种欲望与诱惑,不断学习,不断修炼,不悔昨日,不畏将来!
希望这篇能够带给你们或多或少的帮助,诸位!顶峰见 🚀
一、web开发模式
在web应用中,有两种开发模式:
1.1 前后端混合开发
也可以理解为:前后端不分离开发
前端的一些数据都是在后端通过模板语法渲染好以后再响应给浏览器。
大致开发流程:
- 前端写好静态文件交付给后端作为模板进行开发。
- 后端根据模板语法(变量、以及一些逻辑操作)渲染数据到模板上。
- 遇到模板本身的问题再交付给前端进行修改,然后再交付给后端直到项目开发完成。
缺点:
在前端调试的时候要安装完整的一套后端开发工具,要把后端程序完全启动起来。遇到问题需要后端
开发来帮忙调试。我们发现前后端严重耦合,还要要求后端人员会一些HTML,JS等前端语言。
前端页面里还嵌入了很多后端的代码。一旦后端换了一种语言开发,简直就要重做。
像这种增加了大量的沟通成本,调试成本等,而且前后端的开发进度相互影响,从而大大降低了开发效率。
1.2 前后端分离开发
前后端分离并不只是一种开发模式,也web应用的属于一种架构模式。在开发阶段,前后端工程师需要提前规定好数据交互的接口,实现并行开发测试;推荐采用RESTful接口规范
前后端混合开发:
在传统架构模式中,前后端代码存放于同一个代码库中,甚至是同一工程目录下。页面中还夹杂着后端代码。前后端工程师进行开发时,都必须把整个项目导入到开发工具中。
一但后端更换编程语言,整个项目的后端功能都将需要重新重新开发。
前后端分离开发:
前后端代码库分离,前端代码中有可以进行Mock测试(通过构造虚拟测试对 象以简化测试环境的方法)的伪后端,能支持前端的独立开发和测试。而后端代码中除了功能实现外,还有着详细的测试用例,以保证API的可用性,降低集成风险。
后端即使更换编程语言,只要确保返回的接口前端能够获取需要的数据就不会出现问题。
二、API接口
2.1 简介
为了在团队内部形成共识、防止个人习惯差异引起的混乱,我们需要找到一种大家都觉得很好的接口实现规范,而且这种规范能够让后端写的接口,用途一目了然,减少双方之间的合作成本。
通过网络,规定了前后台信息交互规则的url链接,也就是前后台信息交互的媒介
Web API接口和一般的url链接还是有区别的,Web API接口简单概括有下面四大特点:
- url:长得像返回数据的url链接
- https://api.map.baidu.com/place/v2/search
- 请求方式:get、post、put、patch、delete
- 采用get方式请求上方接口
- 请求参数:json或xml格式的key-value类型数据
- ak:6E823f587c95f0148c19993539b99295
- region:武汉
- query:肯德基
- output:json
- 响应结果:json或xml格式的数据
- 上方请求参数的output参数值决定了响应数据的格式
- 数据
XML格式数据:https://api.map.baidu.com/place/v2/searchak=6E823f587c95f0148c19993539b99295®ion=%E6%AD%A6%E6%B1%89&query=%E8%82%AF%E5%BE%B7%E5%9F%BA&output=xml JSON格式数据:https://api.map.baidu.com/place/v2/search?ak=6E823f587c95f0148c19993539b99295®ion=%E6%AD%A6%E6%B1%89&query=%E8%82%AF%E5%BE%B7%E5%9F%BA&output=json
2.2 RESTful API接口规范
REST全称是Representational State Transfer,中文意思是表述(编者注:通常译为表征性状态转移)。 它首次出现在2000年Roy Fielding的博士论文中。
RESTful是一种定义Web API接口的设计风格,尤其适用于前后端分离的应用模式中。
这种风格的理念认为后端开发任务就是提供数据的,对外提供的是数据资源的访问接口,所以在定义接口时,客户端访问的URL路径就表示这种要操作的数据资源。
事实上,我们可以使用任何一个框架都可以实现符合restful规范的API接口。
1、数据的安全保障
- url链接一般都采用https协议进行传输
注:采用https协议,可以提高数据交互过程中的安全性
2、接口特征表现
- 用api关键字标识接口url:
- https://api.baidu.com
- https://www.baidu.com/api
- 注:看到api字眼,就代表该请求url链接是完成前后台数据交互的
3、多数据版本共存
- 在url链接中标识数据版本
- https://api.baidu.com/v1
- https://api.baidu.com/v2
- 注:url链接中的v1、v2就是不同数据版本的体现(只有在一种数据资源有多版本情况下)
4、数据即是资源,均使用名词(可复数)
-
接口一般都是完成前后台数据的交互,交互的数据我们称之为资源
- https://api.baidu.com/users
- https://api.baidu.com/books
- https://api.baidu.com/book
-
注:一般提倡用资源的复数形式,在url链接中奖励不要出现操作资源的动词,错误示范:https://api.baidu.com/delete-user
-
特殊的接口可以出现动词,因为这些接口一般没有一个明确的资源,或是动词就是接口的核心含义
-
https://api.baidu.com/place/search
-
https://api.baidu.com/login
5、资源操作由请求方式决定(method)
- 操作资源一般都会涉及到增删改查,我们提供请求方式来标识增删改查动作
- https://api.baidu.com/books - get请求:获取所有书
- https://api.baidu.com/books/1 - get请求:获取主键为1的书
- https://api.baidu.com/books - post请求:新增一本书书
- https://api.baidu.com/books/1 - put请求:整体修改主键为1的书
- https://api.baidu.com/books/1 - patch请求:局部修改主键为1的书
- https://api.baidu.com/books/1 - delete请求:删除主键为1的书
6、过滤,通过在url上传参的形式传递搜索条件
- https://api.example.com/v1/zoos?limit=10:指定返回记录的数量
- https://api.example.com/v1/zoos?offset=10:指定返回记录的开始位置
- https://api.example.com/v1/zoos?page=2&per_page=100:指定第几页,以及每页的记录数
- https://api.example.com/v1/zoos?sortby=name&order=asc:指定返回结果按照哪个属性排序,以及排序顺序
- https://api.example.com/v1/zoos?animal_type_id=1:指定筛选条件
7、响应状态码
-
7.1 正常响应
- 响应状态码2xx
- 200:常规请求
- 201:创建成功
- 响应状态码2xx
-
7.2 重定向响应
- 响应状态码3xx
- 301:永久重定向
- 302:暂时重定向
- 响应状态码3xx
-
7.3 客户端异常
- 响应状态码4xx
- 403:请求无权限
- 404:请求路径不存在
- 405:请求方法不存在
- 响应状态码4xx
-
7.4 服务器异常
- 响应状态码5xx
- 500:服务器异常
- 响应状态码5xx
8、错误处理,应返回错误信息,error当做key
{
error: "无权限操作"
}
9、返回结果,针对不同操作,服务器向用户返回的结果应该符合以下规范
- GET /collection:返回资源对象的列表(数组)
- GET /collection/resource:返回单个资源对象
- POST /collection:返回新生成的资源对象
- PUT /collection/resource:返回完整的资源对象
- PATCH /collection/resource:返回完整的资源对象
- DELETE /collection/resource:返回一个空文档
10、响应中携带URL
Hypermedia API,RESTful API最好做到Hypermedia,即返回结果中提供链接,连向其他API方法,使得用户不查文档,也知道下一步应该做什么
{
"status": 0,
"msg": "ok",
"results":[
{
"name":"肯德基",
"img": "https://image.baidu.com/kfc/001.png"
}
...
]
}