什么是REST
表述性状态转移(REpresentation State Transfer, REST)描述了一个架构样式的网络系统,比如Web应用。它首次出现在2000年Roy Fielding的博士论文Architectural Styles and the Design of Network-based Software Architectures
REST API应该具备的条件
- REST API不应该依赖于任何通信协议,尽管要成功映射到某个协议可能会依赖于元数据得可用性、所选的方法等。
- REST API不应该包含通信协议的任何改动,除非是补充或确定标准协议中未规定得部分
- REST API应该将大部分的描述工作放在定义用于表示资源和驱动引用状态的媒体类型上,或定义现有标准媒体类型得扩展关系名和(或)支持超文本得标记
- REST API绝不应该定义一个固定的资源名或层次结构(客户端和服务器之间的明显耦合)。
- REST API永远也不应该有那些会影响客户端的“类型化”资源。
- REST API不应该要求有先验知识(Prior Knowledge),除了初始化URI和适合目标用户的一组标准化的媒体类型(即,它能被任何潜在使用该API的客户端理解)
REST并非标准,而是一种开发Web应用的架构风格,可以将其理解为一种设计模式。REST基于HTTP、URI以及XML这些现有的广泛流行的协议和标准。
REST设计原则
- 通过URI来标识资源。系统中的没一个对象或资源都可以通过一个唯一的URI来进行寻址,URI的结构应该简单、可预测且易于理解,比如定义目录结构式的URI。
- 统一接口。以遵循RFC-2616所定义的协议的方式显示地使用HTTP方法,建立创建、检索、更新和删除操作与HTTP方法之间的一对一映射。
- 若要在服务器上创建资源,应该使用POST方法。
- 若要检索某个资源,应该使用GET方法
- 若要更新或者添加资源,应该使用PUT方法
- 若要删除某个资源,应该使用DELETE方法
- 资源多重表述。URI所访问的每个资源都可以使用不同的形式加以表示(比如XML或者JSON),具体的表现形式取决于访问资源的客户端,客户端与服务提供者使用一种内容协商的机制(请求头与MIME类型)来选择合适的数据格式,最小化彼此之间的数据耦合。在REST世界中,资源即状态,而互联网就是一个巨大的状态机,每个网页是其一个状态;URI是状态的表述;REST风格的应用则是从一个状态迁移到下一个状态的状态转移过程。早期的互联网只有静态页面,通过超链接在静态页面之间浏览跳转的模式就是一个典型的状态转移过程。也就是说,早期的互联网就是天然的REST。
- 无状态。对服务器的请求应该是无状态的,完整、独立的请求不要求服务器在处理请求时检索任何类型的应用程序上下文或状态。无状态约束使服务器的变化对客户端是不可见的,因为在两次连续的请求中,客户端并不依赖于同一台服务器。一个客户端从某台服务器上收到一份包含连接的文档,当它要做一些处理时,这台服务器宕机了,可能是硬盘坏掉而被拿去修理,也可能是软件需要升级重启——如果这个客户端访问了从这台服务器接收的链接,它不会察觉到后台的服务器已经改变了。
HTTP请求方法在RESTful Web服务中的典型应用
资源 | GET | PUT | POST | DELETE |
---|---|---|---|---|
一组资源的URI | 列出URI,以及该资源组中每个资源的详细信息(后者可选) | 使用给定的一组资源替换当前整组资源 | 在本组资源中创建追加一个新的资源。该操作往往返回新资源的URI | 删除整租资源 |
单个资源的URI | 获取指定的资源的详细信息,格式可以自选一个合适的网络媒体类型(比如XML、JSON等) | 替换/创建指定的资源,并将其追加到相应的资源组 | 把指定的资源当作一个资源组,并在其下创建/追加一个新的元素,使其隶属于当前的资源 | 删除指定的元素 |