RESTful服务，就不是什么高大上的东西，很基础的http请求而已。不说了，捞干的
RESTful服务 2. 什么是REST REST不是”rest”这个单词，而是几个单词的缩写 REpresentation State Transfer，直接翻译：表现层状态转移，这个翻译不太好理解。 网上找到一个比较通俗的说法是：URL定位资源，用HTTP动词（GET，POST，DELETE，PUSH等）描述操作
也可以说是：表现层状态转化 3. 什么是Restful 基于REST构建的API就是Restful风格。
举一个实际的例子： 比如用户愚公币交易记录列表， PC网站里需要这个功能，Android App里面也需要这个功能，IOS App里面也需要这个功能。 按照我们现有的开发模式，我们就要写了2套(PC和APP端)获取用户说说列表的功能。 也就是需要在2个地方都写连接数据库配置信息，查询数据库，可想而知是非常浪费时间和经历的， 而且安全性能很差(如果将数据库连接的配置写在Android里面)，RestfulAPI就能较好的解决这个问题: (以下接口不存在，仅仅是举例) 愚公币交易查询 PC: http://******.yugyg.com/user/get YgfMoneyDeal?from=PC 愚公币交易查询安卓: http://******.yugyg.com/user/getYgfMoneyDeal?from=android 愚公币交易查询 IOS: http://******.yugyg.com/user/getYgfMoneyDeal?from=ios 带来好处是只要写一次接口就可以供3个地方同时使用，这样不仅更加安全，快捷，最主要是分工更快速了。 一个人专门写接口，另外一个人只需要知道如何调用就可以了，完全不需要知道是如何实现的。 5. 如何设计Restful风格的API RestfulAPI就是由后台(SERVER端)来提供接口，前端来调用。 前端调用API向后台发起HTTP请求，后台响应请求将处理结果反馈给前端。 也就是说Restful 是典型的基于HTTP的协议。 那么RESTful API有哪些特征呢？ (1).Resource资源，首先是弄清楚资源的概念。 资源就是网络上的一个实体、一段文本、一张图片或者一首歌曲。资源总是要通过一种载体来反应它的内容。 文本可以用TXT，也可以用HTML或者XML、图片可以用JPG格式或者PNG格式，JSON是现在最常用的资源表现形式。 (2).统一接口。Restful风格的数据元操作CRUD(create,read,update,delete)分别对应HTTP方法：(这句话就是执行什么样的逻辑给出一个对应的对应的控制器方法就好了) GET用来获取资源，POST用来新建资源(也可以用于更新资源)，PUT用来更新资源，DELETE用来删除资源，这样就统一了数据操作的接口。 (3).HTTP状态码，在REST中都有特定的意义：200，201，202，204，400，401，403，500。比如401表示用户身份认证失败，403表示你验证身份通过了，但这个资源你不能操作。 (4). 无状态。所谓无状态即所有的资源都可以URI定位，而且这个定位与其他资源无关，也不会因为其他资源的变化而变化。 Restful 是典型的基于HTTP的协议， HTTP连接最显著的特点是客户端发送的每次请求都需要服务器回送响应，在请求结束后，会主动释放连接。 从建立连接到关闭连接的过程称为“一次连接”。前面一次请求与后面一次请求没有必然的联系，所以是无状态的。 TCP/IP要建立一个连接，需要经过三次握手，可以简单的理解为： ①.客户端发起连接请求，等待服务器响应 ②.服务器接收到请求，确认客户端发起的包，并多返回一个包 ③.客户端接收服务器发过来的包，并且回复给服务器确认包，至此三次握手完成，连接建立 握手过程中传送的包里不包含数据，三次握手完毕后，客户端与服务器才正式开始传送数据。 理想状态下，TCP连接一旦建立，在通信双方中的任何一方主动关闭连接之前，TCP 连接都将被一直保持下去。所以TCP/IP是有状态的。 有状态和无状态的区别，举个例子说明一下，例如要查询员工工资的步骤为: 第一步：登录系统。 第二步：进入查询工资的页面。 第三步：搜索该员工。 第四步：点击姓名查看工资。 这样的流程就是有状态的，查询工资的每一个步骤都依赖于前一个步骤，只要前置操作不成功，后续操作就无法执行. 如果输入一个URL就可以得到指定员工的工资，则这种情况就是无状态的，因为获取工资不依赖于其他资源或状态， 且这种情况下，员工工资是一个资源，由一个URL与之对应可以通过HTTP中的GET方法得到资源， 这就是典型的Restful风格。 (5).将API的版本号放入URL。GET:http://www.xxx.com/v1/friend/123。或者将版本号放在HTTP头信息中，我个人觉得版本号能够较好的控制缓存问题，推荐放在HTTP头信息中。 [ApiVersion("1.0")] [Route("api/v{version:apiVersion}/[controller]/[action]")] [ApiController] (6).过滤信息。如果记录数量很多，服务器不可能都将它们返回给用户。API应该提供参数，过滤返回结果。下面是一些常见的参数： ?limit=10：指定返回记录的数量。 ?current_page=2&showCount=10：指定第几页，以及每页的记录数。 ?search_type=1：指定筛选条件。 (7). 规范返回的数据。为了保障前后端的数据交互的顺畅，建议规范数据的返回，并采用固定的数据格式封装。 { "msg":"uri_not_found", "code":10001, "request":"GET/v2/goods/1227" } 6. 采用Restful风格的API可以方便测试 SpringMVC项目可以通过整合springfox和swagger-ui来构建API接口文档，整合过程可以参考: https://my.oschina.net/wangmengjun/blog/907679 后台通过规范的写法，通过IP+端口号+项目名/swagger-ui.html来访问生成的API接口文档: 7. REST API版本控制 随着我们需求的变更，功能的迭代，API的更改是不可避免的。 当一个API修改时，可能会新增一个参数，也有可能会修改返回的数据类型，也有可能删除某个函数…… REST不提供任何特定的版本控制指南，但更常用的方法可以分为3种： （1）.URL版本控制 使用URI是最直接的方法，尽管它违背了URI应该引用唯一资源的原则。当版本更新时，还可以保障客户端不会受到影响，如： http://******.yugyg.com/v1 http://******v1.yugyg.com 版本不需要是数字的，也不需要使用“v[x]”语法指定。替代方案包括日期、项目名称、季节或其他标识符，这些标识符对于开发api的团队来说足够有意义，并且随着版本的变化也足够灵活。 （2）. 使用自定义请求头进行版本控制。 自定义头(例如，Accept-version)允许您在版本之间保留uri，尽管它实际上是现有的Accept头实现的内容协商行为的副本，如: $.ajax({ headers: { Accept-version:v1 }, type: "get", success: function (data) { } }); （3）. 版本使用Accept标头 内容协商可以让您保留一组干净的url，但是您仍然需要处理在某些地方服务不同版本内容的复杂性。 这个负担通常会向上转移到您的API接口上，API接口负责确定要发送哪个版本的资源。 最终结果往往是一个更复杂的API，因为客户端在请求资源之前必须知道要指定哪个头，如: Accept:application/ com.yugyg.v1 + json Accept:application / json com.yugyg + = 1.0版本 在实际开发中，API永远不会是完全稳定的。因此，如何管理这种变化很重要。 作者：无锡愚公坊研发团队 链接：https://www.jianshu.com/p/43dae0b83755 来源：简书 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。