Restful API 设计规范实战

Restful API 设计规范

使用的名词而不是动词

不该该使用动词：

/getAllResources
/createNewResources
/deleteAllResources

GET方法和查询参数不能改变资源状态:

若是要改变资源的状态，使用PUT、POST、DELETE。下面是错误的用GET方法来修改user的状态：

GET /users/711?activate
GET /users/711/activate

Rest的核心原则是将你的API拆分为逻辑上的资源。这些资源经过HTTP被操做(GET,POST,PUT,DELETE)

咱们定义资源ticket、user、group:

• GET /tickets # 获取ticket列表

• GET /tickets/12 # 查看某个具体的ticket

• POST /tickets # 新建一个ticket

• PUT /tickets/12 #新建ticket 12

• DELETE /tickets/12 # 删除ticket 12

只须要一个endpoint：/tickets，再也没有其余什么命名规则和url规则了。

一个能够遵循的规则是：虽然看起来使用复数来描述某一个资源看起来特别扭，可是统一全部的endpoint，使用复数使得你的URL更加规整。这让API使用者更加容易理解，对开发者来讲也更容易实现。

处理关联：

• GET /tickets/12/messages # 获取ticket 12的message列表

• GET /tickets/12/messages/5 #获取ticket 12的message 5

• POST /tickets/12/messages 建立ticket 12的一个message

• PUT /tickets/12/messages/5 更新ticket 12的message 5

• DELETE /tickets/12/messages/5 删除ticket 12的message 5

避免层级过深的URI

/ 在url中表达层级，用于按实体关联关系进行对象导航，通常根据id导航。

过深的导航容易致使url膨胀，不易维护，如 GET /zoos/1/areas/3/animals/4，尽可能使用查询参数代替路劲中的实体导航，如GET /animals?zoo=1&area=3。

结果过滤，排序，搜索

url最好越简短越好，对结果过滤、排序、搜索相关的功能都应该经过参数实现。

过滤：例如你想限制GET /tickets 的返回结果：只返回那些open状态的ticket， GET /tickets?state=open 这里的state就是过滤参数。

排序：和过滤同样，一个好的排序参数应该可以描述排序规则，而不和业务相关。复杂的排序规则应该经过组合实现。排序参数经过 , 分隔，排序参数前加 - 表示降序排列。

• GET /tickets?sort=-priority #获取按优先级降序排列的ticket列表

• GET /tickets?sort=-priority,created_at #获取按优先级降序排列的ticket列表，在同一个优先级内，先建立的ticket排列在前面。

搜索：有些时候简单的排序是不够的。咱们可使用搜索技术来实现

• GET /tickets?q=return&state=open&sort=-priority,create_at # 获取优先级最高且打开状态的ticket，并且包含单词return的ticket列表。

限制API返回值的域

有时候API使用者不须要全部的结果，在进行横向限制的同时（例如值返回API结果的前十个），还应该能够进行纵向限制，而且这个功能能有效的提升网络带宽使用率和速度。可使用fields查询参数来限制返回的域例如：

• GET /tickets?fields=id,subject,customer_name,updated_at&state=open&sort=-updated_at

Response不要包装

response 的 body直接就是数据，不要作多余的包装。错误实例：

{
    "success":true,
    "data":{"id":1, "name":"xiaotuan"}
}

更新和建立操做应该返回资源

在POST操做之后，返回201created 状态码，而且包含一个指向新资源的url做为返回头。

命名方式

是蛇形命名仍是驼峰命名？若是使用json那么最好的应该是遵照JavaScript的命名方法-驼峰命名法。Java、C# 使用驼峰，python、ruby使用蛇形。

默认使用pretty print格式，开启gzip

开启pretty print返回结果会更加友好易读，并且额外的传输也能够忽略不计。若是忘了使用gzip那么传输效率将会大大减小，损失大大增长。

GitHub v3S实践经验

1.Current Version

经过Accept字段来区分版本号，而不是在url中嵌入版本号：
Accept: application/vnd.github.v3+json

2.Schema

Summary Representation

当你请求获取某一资源的列表时，响应仅返回资源的属性子集。有些属性对API来讲代价是很是高的，出于性能的考虑，会排除这些属性。要获取这些属性，请求"detailed" representation。

Example：当你获取仓库的列表时，你得到的是每一个仓库的summary representation。

GET /orgs/octokit/repos

Detailed Representation

当你获取一个单独的资源时，响应会返回这个资源的全部属性。

Example：当你获取一个单独的仓库，你会得到这个仓库的detailed representation。

GET /repos/octokit/octokit.rb

3.Parameters

许多API都带有可选参数。对于GET请求，任何不做为路径构成部分的参数均可以经过HTTP查询参数传入。

GET https://api.github.com/repos/vmg/redcarpet/issues?state=closed

在这个例子中，'vmg' 和 'redcarpet' 做为 :owner 和 :repo 的参数，而 :state 做为查询参数。

对于POST、PATCH、PUT和DELETE的请求，不包含在URL中的参数须要编码成JSON传递，且 Content-Type为 'application/json'。

Root Endpoint

你能够对根节点GET请求，获取根节点下的全部API分类。

Client Errors

有三种可能的客户端错误，在接收到请求体时：

1 发送非法JSON会返回 400 Bad Request.

HTTP/1.1 400 Bad Request
Content-Length: 35

{"message":"Problems parsing JSON"}

2 发送错误类型的JSON值会返回 400 Bad Request.

HTTP/1.1 400 Bad Request
Content-Length: 40

{"message":"Body should be a JSON object"}

3 发送无效的值会返回 422 Unprocessable Entity.

HTTP/1.1 422 Unprocessable Entity
Content-Length: 149

{
      "message": "Validation Failed",
      "errors": [
    {
      "resource": "Issue",
      "field": "title",
      "code": "missing_field"
    }
  ]
}

咱们能够告诉发生了什么错误，下面是一些可能的验证错误码：

Error Name	Description
missing	资源不存在
missing_field	资源必需的域没有被设置
invalid	域的格式非法
already_exists	另外一个资源的域的值和此处的相同，这会发生在资源有惟一的键的时候

HTTP Redirects

API v3在合适的地方使用HTTP重定向。客户端应该假设任何请求都会致使重定向。重定向在响应头中有一个 Location 的域，此域包含了资源的真实位置。

HTTP Verbs

API v3力争使用正确的HTTP动词来表示每次请求。

Verb	Description
HEAD	对任何资源仅请求头信息
GET	获取资源
POST	建立资源
PATCH	使用部分的JSON数据更新资源
PUT	取代资源或资源集合
DELETE	删除资源

Hypermedia

不少资源有一个或者更多的 *_url 属性指向其余资源。这意味着服务端提供明确的URL，这样客户端就没必要要本身构造URL了。

Pagination

请求资源列表时会进行分页，默认每页30个。当你请求后续页的时候可使用 ?page 参数。对于某些资源，你能够经过参数 ?per_page自定义每页的大小。

curl 'https://api.github.com/user/repos?page=2&per_page=100'

须要注意的一点是，页码是从1开始的，当省略参数 ?page 时，会返回首页。

Basics of Pagination

关于分页的其余相关信息在响应的头信息的 Link 里提供。好比，去请求一个搜索的API，查找Mozilla的项目中哪些包含词汇addClass :

curl -I "https://api.github.com/search/code?q=addClass+user:mozilla"

头信息中Link字段以下:

Link: <https://api.github.com/search/code?q=addClass+user%3Amozilla&page=2>; rel="next", <https://api.github.com/search/code?q=addClass+user%3Amozilla&page=34>; rel="last"

rel="next" 表示下一页是 page=2。也就是说，默认状况下全部的分页请求都是从首页开始。rel="last" 提供更多信息，表示最后一页是34。即咱们还有33页的信息包含addClass。

总之，咱们应该依赖于Link提供的信息，而不要尝试本身去猜或者构造URL。

Navigating through the pages

既然已经知道会接收多少页面，咱们能够经过页面导航来消费结果。咱们能够经过传递一个page参数，例如跳到14页：

curl -I "https://api.github.com/search/code?q=addClass+user:mozilla&page=14"

这是头信息中Link字段：

Link: <https://api.github.com/search/code?q=addClass+user%3Amozilla&page=15>; rel="next",
  <https://api.github.com/search/code?q=addClass+user%3Amozilla&page=34>; rel="last",
  <https://api.github.com/search/code?q=addClass+user%3Amozilla&page=1>; rel="first",
  <https://api.github.com/search/code?q=addClass+user%3Amozilla&page=13>; rel="prev"

咱们会得到更多的信息，rel="first"表示首页，rel="prev"表示前一页的页码。经过这些信息，咱们能够构造一个UI界面让用户在first、previous、next、last之间进行跳转。

Rate Limiting

对于认证的请求，能够每小时最多请求5000次。对于没有认证的请求，限制在每小时60次请求。

检查返回的HTTP头，能够看到当前的速率限制：

curl -i https://api.github.com/users/whatever   
                                                   
HTTP/1.1 200 OK
Server: GitHub.com
Date: Thu, 27 Oct 2016 03:05:42 GMT
Content-Type: application/json; charset=utf-8
Content-Length: 1219
Status: 200 OK
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 48
X-RateLimit-Reset: 1477540017

header头信息告诉你当前的速率限制状态：

Header Name	Description
X-RateLimit-Limit	当前用户被容许的每小时请求数
X-RateLimit-Remaining	在当前发送窗口内还能够发送的请求数
X-RateLimit-Reset	按当前速率发送后，发送窗口重置的时间

一旦你超过了发送速率限制，你会收到一个错误响应：

HTTP/1.1 403 Forbidden
Date: Tue, 20 Aug 2013 14:50:41 GMT
Status: 403 Forbidden
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1377013266

{
       "message": "API rate limit exceeded for xxx.xxx.xxx.xxx. (But here's the good news: Authenticated requests get a higher rate limit. Check out the documentation for more details.)",
       "documentation_url": "https://developer.github.com/v3/#rate-limiting"
}

User Agent Required

全部的API请求必须包含一个有效的 User-Agent 头。请求头不包含User-Agent的请求会被拒绝。

Conditional requests

大多数响应都会返回一个 ETag 头。不少响应也会返回一个 Last-Modified 头。你可使用这些头信息对这些资源进行后续请求，分别使用 If-None-Match 和 If-Modified-Since头。若是资源没有发生改变，服务器端会返回 304 Not Modified。

Enchant REST API 实践经验

Requests

Limited HTTP Clients

若是你使用的HTTP客户端不支持PUT、PATCH、DELETE方法，发送一个POST请求，头信息里包含X-HTTP-Method-Override字段，它的值是实际须要的动词。

$ curl -u email:password https://site.enchant.com/api/v1/users/543abc \
    -X POST \
    -H "X-HTTP-Method-Override: DELETE"

Rate Limiting

全部响应的头部包含描述当前限流状态的字段:

Rate-Limit-Limit: 100
Rate-Limit-Remaining: 99
Rate-Limit-Used: 1
Rate-Limit-Reset: 20

• Rate-Limit-Limit - 当前时间段内容许的总的请求数

• Rate-Limit-Remaining - 当前时间段内还剩余的请求数

• Rate-Limit-Used - 本次所使用的请求数

• Rate-Limit-Reset - 重置所需秒数

若是速率限制被打破，API会返回 429 Too Many Requests 的状态码。在这种状况下，你的应用不该该再发送任何请求直到 Rate-Limit-Reset 所规定的时间过去。

Field Filtering

你能够本身限制响应返回的域。只须要你传递一个 fields 参数，用逗号分隔所须要的域，好比：

GET /api/v1/users?fields=id,first_name

Counting

全部返回一个集合的URL，都会提供count统计全部结果的个数。要获取count值须要加一个 count=true 的参数。count会在消息头中的Total-Count 字段中返回。

GET /api/v1/tickets?count=true

200 OK
Total-Count: 135
Rate-Limit-Limit: 100
Rate-Limit-Remaining: 98
Rate-Limit-Used: 2
Rate-Limit-Reset: 20
Content-Type: application/json

---

[
  ... results ... 
]

count表示全部现存结果的数量，而不是这次响应返回的结果的数量。

Enveloping

若是你的HTTP客户端难以读取状态码和头信息，咱们能够将全部都打包进响应消息体中。咱们只须要传递参数 envelope=true，而API会始终返回200的HTTP状态码。真正的状态码、头信息和响应都在消息体中。

GET /api/v1/users/does-not-exist?envelope=true

---

200 OK

---

{
      "status": 404,
      "headers": {
    "Rate-Limit-Limit": 100,
    "Rate-Limit-Remaining": 50,
    "Rate-Limit-Used": 0,
    "Rate-Limit-Reset": 25
  },
  "response": {
    "message": "Not Found"
  }
}

其余如 分页、排序等，enchant的设计规范和GitHub v3大体相同，不在赘述。

原文连接

https://segmentfault.com/a/11...