深入浅出REST

在2007年左右的时候,大家围绕着什么才是正确的异构通信规则有一个广泛的讨论,Stefan Tilkov对REST这一通信规则做了比较详细的解释。告诉我们为什么这是一个好的规则,以及如何使用这样的规则。

REST关键原则

如果你在设计应用程序时能坚持REST原则,那就预示着你将会得到一个使用了优质Web架构(这将让你受益)的系统。总之,五条关键原则列举如下:

  1. 为所有的事物定义ID
  2. 将所有的事物连接在一起
  3. 使用标准方法
  4. 资源多重表述
  5. 无状态通信

关键原则解释

每个事物都应该是可标识的,都应该拥有一个明显的ID——在Web中,代表ID的统一概念是:URI。URI构成了一个全局命名空间,使用URI标识你的关键资源意味着它们获得了一个唯一、全局的ID。而链接是构成动态应用的非常有效的方式。

所有的资源都应该使用标准的方式进行访问,以支持客户端的状态转移,所有的资源都应该继承一个类似于下面的类:

class Resource {
     Resource(URI u);
     Response get();
     Response post(Request r);
     Response put(Request r);
     Response delete();
} 

由于所有资源使用了同样的接口,因此不同架构的客户端都能够根据预设的定义来对资源进行操作。统一接口也使得所有理解HTTP应用协议的组件能与你的应用交互。

客户程序如何知道该怎样处理检索到的数据,比如作为GET或者POST请求的结果?如果客户程序对HTTP应用协议和一组数据格式都有所“了解”,那么它就可以用一种有意义的方式与世界上任意一个RESTful HTTP应用交互。倘若从客户端传来的数据符合应用协议,那么服务器端就可以使用特定的格式处理数据,而不去关心客户端的类型。

虽然REST包含无状态性(statelessness)的观念,但这并不是说暴露功能的应用不能有状态。REST要求状态要么被放入资源状态中,要么保存在客户端上。或者换句话说,服务器端不能保持除了单次请求之外的,任何与其通信的客户端的通信状态。这样做的最直接的理由就是可伸缩性。但除此以外,其它方面可能显得更为重要:无状态约束使服务器的变化对客户端是不可见的。

后记

  1. 深入浅出REST
  2. HTTP API设计指南