REST简介

发表于 | 更新于 | 分类于

REST （ REpresentational State Transfer，现层状态转移）

URL 定位资源，用 HTTP 动词（GET,POST,DELETE,DETC ）描述操作。 Web 端不再用之前典型的 PHP 或 JSP 架构，而是改为前段渲染和附带处理简单的商务逻辑（比如 AngularJS 或者 BackBone 的一些样例）。 Web 端和 Server 只使用上述定义的 API 来传递数据和改变数据状态。格式一般是 JSON。iOS 和 Android 同理可得。由此可见，Web ， iOS，Android 和第三方开发者变为平等的角色通过一套 API 来共同消费 Server 提供的服务。

REST 架构该怎么生动地理解？http://www.zhihu.com/question/27785028 RESTful API 设计指南http://www.ruanyifeng.com/blog/2014/05/restful_api.html 如何获取（GET ）一杯咖啡 —— 星巴克 REST 案例分析http://www.infoq.com/cn/articles/webber-rest-workflow/

  • REST 描述的是在网络中 client 和 server 的一种交互形式；REST 本身不实用，实用的是如何设计 RESTful API（REST 风格的网络接口）；
  • Server 提供的 RESTful API 中，URL 中只使用名词来指定资源，原则上不使用动词。“ 资源 ” 是 REST 架构或者说整个网络处理的核心。

  • 用 HTTP 协议里的动词来实现资源的添加，修改，删除等操作。即通过 HTTP 动词来实现资源的状态扭转：

    GET 用来获取资源， POST 用来新建资源（也可以用于更新资源）， PUT 用来更新资源， DELETE 用来删除资源。

  • Server 和 Client 之间传递某资源的一个表现形式，比如用 JSON，XML 传输文本，或者用 JPG，WebP 传输图片等。当然还可以压缩 HTTP 传输时的数据（on-wire data compression ）。

  • 用 HTTP Status Code 传递 Server 的状态信息。比如最常用的 200 表示成功，500 表示 Server 内部错误等。

RESTful

大家都知道 “ 古代 “ 网页都是前端后端融在一起的，比如之前的 PHP，JSP 等。在之前的桌面时代问题不大，但是近年来移动互联网的发展，各种类型的 Client 层出不穷，RESTful 可以通过一套统一的接口为 Web，iOS 和 Android 提供服务。另外对于广大平台来说，比如 Facebook platform，微博开放平台，微信公共平台等，它们不需要有显式的前端，只需要一套提供服务的接口，于是 RESTful 更是它们最好的选择。

HTTP 动词

对于资源的具体操作类型，由 HTTP 动词表示：常用的 HTTP 动词有下面五个（括号里是对应的 SQL 命令）。

  • GET（SELECT ）：从服务器取出资源（一项或多项）。
  • POST（CREATE ）：在服务器新建一个资源。
  • PUT （ UPDATE）：在服务器更新资源（客户端提供改变后的完整资源）。
  • PATCH（UPDATE ）：在服务器更新资源（客户端提供改变的属性）。
  • DELETE（DELETE ）：从服务器删除资源。

还有两个不常用的 HTTP 动词：

  • HEAD ：获取资源的元数据。
  • OPTIONS ：获取信息，关于资源的哪些属性是客户端可以改变的。

下面是一些例子。 GET /zoos ：列出所有动物园 POST /zoos：新建一个动物园 GET /zoos/ID：获取某个指定动物园的信息 PUT /zoos/ID：更新某个指定动物园的信息（提供该动物园的全部信息） PATCH /zoos/ID ：更新某个指定动物园的信息（提供该动物园的部分信息） DELETE /zoos/ID ：删除某个动物园 GET /zoos/ID/animals：列出某个指定动物园的所有动物 DELETE /zoos/ID/animals/ID：删除某个指定动物园的指定动物

过滤信息（Filtering ）

如果记录数量很多，服务器不可能都将它们返回给用户。API 应该提供参数，过滤返回结果。下面是一些常见的参数：

  • ?limit=10 ：指定返回记录的数量
  • ?offset=10：指定返回记录的开始位置。
  • ?sortby=name&order=asc ：指定返回结果按照哪个属性排序，以及排序顺序。
  • ?animal typeid=1 ：指定筛选条件

参数的设计允许存在冗余，即允许 API 路径和 URL 参数偶尔有重复。比如，GET /zoo/ID/animals 与 GET /animals?zoo_id=ID 的含义是相同的。

状态码（Status Codes ）

一般的基于 Web 的集成，我们还需要其他一些有用的状态代码：

  • 200 OK—— 它的意思是：一切正常；继续执行。
  • 201 Created—— 我们刚刚创建了一个资源，一切正常。
  • 202 Accepted—— 服务已经接受了我们的请求，并请我们对 Location 响应报头里的 URI 进行轮询（poll ）。这在异步处理中相当有用。
  • 303 See Other—— 我们需要跟另一个资源交互，应该不会出错。
  • 400 Bad Request—— 我们的请求格式有问题，应重新格式化后再提交。
  • 404 Not Found—— 服务因为偷懒（或者保密）没有告知请求失败的真实原因，但不管什么原因，我们都得应付它。
  • 409 Conflict—— 服务器拒绝了我们更新资源状态的请求。我们需要获取资源的当前状态（要么检查响应实体主体，要么做一次 GET 操作），然后再作打算。
  • 412 Precondition Failed—— 请求未被处理，因为 Etag、If-Match 或类似的 “ 哨兵（guard ） ” 报头的值不满足条件。我们需要考虑下一步怎么走。
  • 417 Expectation Failed—— 幸亏核查一下，服务器不将接受你的请求，所以别真正发送那个请求。
  • 500 Internal Server Error—— 最偷懒的响应。服务器出错了，而且什么原因都没说。祝你不要碰见它。
0%