REST 全称Representational State Transfer, 阮一峰翻译为“表现层状态转化”理解RESTful架构，维基百科“具象状态传输”。
它描述了一个系统如何与另一个交流。比如一个产品的状态(名字，详情)表现为XML，JSON或者普通文本。

REST 有六个约束：

• 统一的接口
  • 统一的接口约束定义客户端和服务器之间的接口。它简化并且解耦架构，让每个部分独立发展。统一接口的四项指导原则是：

  • 基于资源的(Resource-Based)

    各个资源使用URI作为资源标识符表示的请求。资源本身概念性的从被返回的客户端的表现层分开。比如：服务器不发送它的数据库，而是一些HTML，XML或者JSON代表数据库记录表现。比如，在Finnish和UTF-8编码，取决于请求的细节和服务器的实现。

  • 通过表现层操作资源(Manipulation of Resources Through Representations)

    当客户端持有一个资源的表现，包含附加的元数据，它就有足够的信息区修改或者删除资源如果服务器有提供权限

  • 自我描述消息(Self-descriptive Message)

每个消息包含了足够的信息描述如何处理消息。比如，使用哪个解析器调用可能被指定的Internet媒体类型。返回页明确的指定它们的缓存能力
* 超媒体作为应用状态的引擎(Hypermedia as the Engine of Application State (HATEOAS))
客户端通过body内容，query-string参数，请求头(request-headers)和请求URI(resource name)传递状态。服务器通过body内容，返回码(response codes)和返回头(response headers)传递状态。这在技术上成为对超媒体(或超文本来的超链接)
出了上述说明，HATEOS也意味着，在必要时，链接被包含在返回体(body)或者头(headers)去检索对象本身或者相关的对象提供URI。

• 无状态的(stateless)
  知道REST是Representational State Transfer的缩写，无状态是关键。
• 可缓存的(Cacheable)
• 客户端-服务器(Client-Server)
• 分层系统(Layered System)
• 按需代码(可选)

REST是设计风格而不是标准。

RESTful架构：

• 每一个URI代表一种资源
• 客户端和服务器之间，传递这种资源的某种表现层；
• 客户端通过几个HTTP动词，对服务器端资源进行操作，实现"表现层状态转化"。
  动词分别是
• GET：用来获取资源，GET操作应该是幂等(idempotence)的，且无副作用
• POST：用于新建资源(也可用于修改资源)
• PUT：替换某个已有的资源。PUT操作虽然有副作用，但其应该是幂等的。
• DELETE：用于删除资源。DELETE操作有副作用，但也是幂等的。
• PATCH(RFC5789) ：修改某个已有的资源

幂等：相同的数据和参数下，执行一次或多次产生的效果(副作用)是一致性的。

对于REST API来说，有一些HTTP headers很重要：

• Accept：服务器需要返回什么样的content。如果客户端要求返回"application/xml"，服务器端只能返回"application/json"，那么最好返回status code 406 not acceptable（RFC2616），当然，返回application/json也并不违背RFC的定义。一个合格的REST API需要根据Accept头来灵活返回合适的数据。
• If-Modified-Since/If-None-Match：如果客户端提供某个条件，那么当这个条件满足时，才返回数据，否则返回304 not modified。如果客户端已经缓存了某个数据，它只想看看有没有新的数据时，会用这两个header之一，服务器如果不理睬，依旧返回200 ok的话，就显得不专业也不高效。
• If-Match：在对某个资源做PUT/PATCH/DELETE操作时，服务器应该要求客户端提供If-Match头，只有客户端提供的Etag与服务器对应资源的Etag一致，才进行操作，否则返回412 precondition failed。

Status code
返回的status code也应该规范，可参考clojure下的liberator

转载自微信公众号：程序人生