RESTful规范

目录

REST

RESTful架构

RESTful特点

RESTful api接口开发

---

REST

REST（Representational Status Transfer，表述性状态转换）可以理解为是一组架构约束条件和规则。REST当中的资源并不仅仅是指数据，而是指数据和表现形式的组合。

在三种主流的的Web服务交换方案中，REST相比较SOAP和XML-PRC更加简单明了，无论是对URL还是Payload（这里指有效数据主体）的编码，REST都倾向于使用更加简单轻量的方法设计和实现。

提示：

SOAP（Simple Object Access ，简单对象访问协议）基于HTTP协议和XML，是一种标准化的通信规范，主要用于Web服务中。

XML-PRC是一种使用HTTP协议作为传输协议，以XML文本的方式传输命令和数据的RPC机制，而PRC（Remote Procedure Call Protocol，远程过程调用协议）是一种通过网络向远程计算机程序请求服务，而不需要了解底层网络技术的协议。

RESTful架构

满足REST的应用程序或设计就是RESTful。

RESTful是一种软件架构风格、设计风格，而非标准。RESTful只是提供了一组设计规则和约束条件，主要用于互联网软件。基于RESTful标准设计的软件可以更简洁，更有层次，更易于实现缓存等机制。

RESTful架构，是一种对MVC架构进行改进后所形成的的架构，通过使用事先定义好的接口与不同的服务联系起来。RESTful是通过对URI来实现对资源的管理和访问，具有结构清晰、拓展性强的特点。

RESTful架构将服务器分为前端服务器和后端服务器两部分，前端服务器为用户提供无模型的视图，后端服务器为前端服务器提供接口，浏览器向前端服务器请求视图，通过视图中包含的Ajax函数发起接口请求获取模型。

项目开发引入RESTful架构，利于团队并行开发。在RESTful架构中，将多数HTTP请求转移到前端服务器上，降低服务器的负荷，使视图获取后端模型失败时也能呈现。

RESTful特点

1.每一种URI代表一种资源。资源应该用名词表示，所以不应该在URI中使用动词。

2.客户端使用GET、POST、PUT、DELETE四个表示操作方式的动词对服务端资源进行操作。GET用于获取资源，POST用于新建资源（也可以更新资源），PUT用于更新资源，DELETE用于删除资源。

3.通过操作资源的表现形式来操作资源。

4.资源的表现形式是XML或者HTML。

5.客户端与服务器端的交互在请求之间是无状态的，从客户端到服务器端的每个请求都必须包含理解请求所必须的信息。

RESTful api接口开发

1.开发RESTful api接口时，建议使用https协议，以保障交互数据的传输安全。

2.正确设置http状态码，不要自定义。

3.不要发生了错误但给2XX响应，客户端可能会缓存成功的http请求。

4.API响应客户端请求返回的数据格式，不应该是纯文本，而应该是一个json对象，因为json对象是一个标准的的结构化数据。因此，服务器回应的HTTP头的Content-Type要设置为application/json，客户端请求时，也要明确告诉服务器，可以接收json格式，即请求的HTTP头的ACCEPT属性也要设为application/json。

之所以API响应客户端请求返回的数据格式一般选择json，而不是xml，这是因为一般json相比较xml，数据格式比较简单，易于读写，格式是压缩的，占用的带宽小，而且易于解析，支持多种语言。

5.业务类异常的话必须提供两种信息。一是如果抛出该类异常，应该设置正确的HTTP响应状态码。二是关于异常的文本描述。

6.API的使用者，不一定知道URL是怎么设计的，所以可以在回应里提供相关链接，便于下一步操作。这样，用户只需要记住一个URL，就可以发现其它的URL，这种方法叫做HATEOAS。HATEOAS（Hypermedia as the engine of application state，超媒体作为应用程序状态引擎）是REST应用程序体系结构里的一个组件。

7.可以使用Auth2.0的方式为API调用者提供登录认证。

8.比较复杂的接口不能确定是使用POST还是PUT时，要看具体的业务代码，看看接口产生的结果是否幂等，如果幂等用PUT，不幂等用POST。例如接口接收到一资源，该资源只存在更新，而不存在插入新数据，这时就应该用PUT。