绿蚁新醅酒，红泥小火炉。晚来天欲雪，能饮一杯无。
2020年的冬季已渐深，白居士的流露出的和三两好友围炉夜话的场景，成为了“打工人”下班之后，很受喜爱的社交活动了。希望大家都在忙碌的同时都能够抽出一定的时间，联系联系老友，关心关心父母。 好了，煽情结束了~ 开始进入正题吧！
背景交代：
随着项目发展，整体项目变的越来越大，开发人员经常陷入一个困境：维护老功能变的越来越难，新功能不断的增加。此时，会出现一个问题，就是项目中以往版本的接口与现阶段接口的兼容性的问题。这个问题也在我们项目中出现了，由于之前的版本控制和接口规范没有做好，导致项目难以为继，所以作者花了一段时间研究关于项目中的接口规范以及版本控制相关的问题，也就引出了本文的产生原因。下面会从：RESTl接口规范，以及作者在项目中的具体实现，以及对于REST接口规范的思考。
熟悉又陌生的Rest接口规范：
最近几年Rest大火，但是在开发过程中，不知道大家对于Restful的认知处于哪一层呢？是否接口的名称还是随心所欲的定义呢？
Rest之父Roy Fielding曾经说过：
REST提供了一系列架构约束，当作为整体使用时，它强调组件交互的可扩展性、接口的通用性、组件的独立部署，以及那些能够较少交互延迟的中间件，它强化了安全性，也能封装遗留系统。
REST中的一个关键概念是资源，它通常表示单个业务对象。REST使用HTTP动词来操作资源，使用URL引用这些资源。例如，使用GET请求获取返回的资源，使用POST请求创建新的资源，使用PUT请求更新资源等。上述的内容大家或许在开发过程中，都或多或少的使用过，为了让大家更加的理解REST的概念，我们下面看一看REST的成熟度模型。
REST成熟度模型：
-
Level0: Level0层级服务的客户端只是=向服务端点发起HTTP POST请求，进行服务调用。每个请求都指明了需要执行的操作、这个操作针对的目标和表要的参数。
-
Level1: Level1层级引入了资源的概念。要执行资源的操作，客户端需要发出指定要执行的操作和包含任何参数的POST请求。
-
Level2: Level2层级的服务使用HTTP动词来执行操作，例如：使用GET请求获取、POST请求表示创建、、PUT表示更新。请求查询的参数执行操作的参数。
-
Level3：Level3层级的服务的基本思想是在由GET请求返回的资源信息中包含链接，这些链接能够执行该资源允许的操作。例如：当创建完成一个订单数据之后，在创建完成的响应中，应当返回本次创建的订单，客户端可以执行的操作，例如：客户端可以根据返回的链接对订单进行取消、删除等操作。
大家可以对比一下，自己的项目中对于REST的使用已经到达了何种层级了哦！ 说了这么多的REST的基础定义，相信大家现在已经想要磨拳擦掌对自己的项目中的接口进行一番升级了！少年，骚等！我这还有一些作者实践下来的一些经验，你确定不看看嘛？
对于资源的定义
-
1.推荐使用名词复数来进行资源的定义，例如对于订单的资源，推荐使用 /orders/来定义；
-
2.推荐使用HTTP动词来对资源进行操作，定义资源在项目中的实际实践可以理解为对于一块业务的操作，我们可以将这部分业务理解为一个资源，例如：电商项目中的订单服务，我们就可以将订单理解为一个资源，我们可以使用POST /orders/来进行订单的创建，GET /orders/{orderId}/来获取订单信息，PUT /orders/{orderId}/进行订单的更新等；
-
3.使用正确的HTTP响应码，并提示详细的错误提示；
-
4.对于某些非资源型的操作，应当使用相应的动词来进行请求。
-
5.在接口相应中加入相关资源的链接。创建订单后的相应结果如下：
{
"orderId": 1,
"name": "Paul",
"links": [{
"method": "GET",
"rel": "orders",
"href": "/orders/1/"
},
{
"method": "PUT",
"rel": "orders",
"href": "/orders/1/"
},
{
"method": "DELETE",
"rel": "orders",
"href": "/orders/1/"
}
]
}
响应中的链接包含了客户端对订单的可执行操作。
REST接口规范的思考
就像任何事情一样，它都是具有两面性的，REST也是如此。
REST优点：
1.简单且大家相对熟悉。
2.可以使用浏览器扩展（例如Postman插件）或者curl之类的命令行来测试HTTP API。
3.直接支持请求/响应方式的通信。
4.HTTP对防火墙友好。
5不需要中间代理，简化了系统架构。
REST缺点：
1.它支持请求/响应方式的通信。
2.可能导致可用性降低。
3.客户端必须知道服务实例的位置（URL）。
4.在单个请求中获取多个资源具有挑战性。
5.有时很难将多个更新操作映射到HTTP动词。
总结
虽然REST有这么多的缺点，但是也无法阻挡其近些年的发展势头，本文简单介绍了REST的相关的概念以及笔者自己项目中实践，最后对REST接口现存的优缺点进行了比较。希望本文能够对大家在REST的认识上有提升，那这篇文章的价值也就有价值了。
下回见，我是喜欢研究源码的小菜鸡。
