关于restful API url整理

 

每一个资源使用两个URL

资源集合用一个URL，具体某个资源用一个URL：

1. /employees         #资源集合的URL

2. /employees/56      #具体某个资源的URL

用名词代替动词表示资源

这让你的API更简洁，URL数目更少。不要这么设计：

1. /getAllEmployees

2. /getAllExternalEmployees

3. /createEmployee

4. /updateEmployee

更好的设计：

1. GET /employees

2. GET /employees?state=external

3. POST /employees

4. PUT /employees/56

用HTTP方法操做资源

使用URL指定你要用的资源。使用HTTP方法来指定怎么处理这个资源。使用四种HTTP方法POST，GET，PUT，DELETE能够提供CRUD功能（建立，获取，更新，删除）。

• 获取：使用GET方法获取资源。GET请求从不改变资源的状态。无反作用。GET方法是幂等的。GET方法具备只读的含义。所以，你能够完美的使用缓存。

• 建立：使用POST建立新的资源。

• 更新：使用PUT更新现有资源。

• 删除：使用DELETE删除现有资源。

2个URL乘以4个HTTP方法就是一组很好的功能。看看这个表格：

	POST（建立）	GET（读取）	PUT（更新）	DELETE（删除）
/employees	建立一个新员工	列出全部员工	批量更新员工信息	删除全部员工
/employees/56	（错误）	获取56号员工的信息	更新56号员工的信息	删除56号员工

对资源集合的URL使用POST方法，建立新资源

建立一个新资源的时，客户端与服务器是怎么交互的呢？

在资源集合URL上使用POST来建立新的资源过程：

1. 客户端向资源集合URL /employees发送POST请求。HTTP body 包含新资源的属性 “Albert Stark”。

2. RESTful Web服务器为新员工生成ID，在其内部模型中建立员工，并向客户端发送响应。这个响应的HTTP头部包含一个Location字段，指示建立资源可访问的URL。

对具体资源的URL使用PUT方法，来更新资源

使用PUT更新已有资源：

1. 客户端向具体资源的URL发送PUT请求 /employee/21。请求的HTTP body中包含要更新的属性值（21号员工的新名称“Bruce Wayne”）。

2. REST服务器更新ID为21的员工名称，并使用HTTP状态码200表示更改为功。

推荐用复数名词

推荐：

1. /employees

2. /employees/21

不推荐：

1. /employee

2. /employee/21

事实上，这是我的爱好问题，但复数形式更为常见。此外，在资源集合URL上用GET方法，它更直观，特别是 GET/employees?state=external、 POST/employees、 PUT/employees/56。但最重要的是：避免复数和单数名词混合使用，这显得很是混乱且容易出错。

对可选的、复杂的参数，使用查询字符串（？）。

不推荐作法：

1. GET /employees

2. GET /externalEmployees

3. GET /internalEmployees

4. GET /internalAndSeniorEmployees

为了让你的URL更小、更简洁。为资源设置一个基本URL，将可选的、复杂的参数用查询字符串表示。

1. GET /employees?state=internal&maturity=senior

使用HTTP状态码

RESTful Web服务应使用合适的HTTP状态码来响应客户端请求

• 2xx - 成功 - 一切都很好

• 4xx - 客户端错误 - 若是客户端发生错误（例如客户端发送无效请求或未被受权）

• 5xx – 服务器错误 - 若是服务器发生错误（例如，尝试处理请求时出错） 参考维基百科上的HTTP状态代码。可是，其中的大部分HTTP状态码都不会被用到，只会用其中的一小部分。一般会用到一下几个：

2xx：成功	3xx：重定向	4xx：客户端错误	5xx：服务器错误
200 成功	301 永久重定向	400 错误请求	500 内部服务器错误
201 建立	304 资源未修改	401未受权
		403 禁止
		404 未找到

返回有用的错误提示

除了合适的状态码以外，还应该在HTTP响应正文中提供有用的错误提示和详细的描述。这是一个例子。 请求：

1. GET /employees?state=super

响应：

1. // 400 Bad Request

2. {

3.    "message": "You submitted an invalid state. Valid state values are 'internal' or 'external'",

4.    "errorCode": 352,

5.    "additionalInformation" :

6.    "http://www.domain.com/rest/errorcode/352"

7. }

使用小驼峰命名法

使用小驼峰命名法做为属性标识符。

1. { "yearOfBirth": 1982 }

不要使用下划线（ year_of_birth）或大驼峰命名法（ YearOfBirth）。一般，RESTful Web服务将被JavaScript编写的客户端使用。客户端会将JSON响应转换为JavaScript对象（经过调用 varperson=JSON.parse(response)），而后调用其属性。所以，最好遵循JavaScript代码通用规范。
对比：

1. person.year_of_birth // 不推荐，违反JavaScript代码通用规范

2. person.YearOfBirth // 不推荐，JavaScript构造方法命名

3. person.yearOfBirth // 推荐

在URL中强制加入版本号

从始至终，都使用版本号发布您的RESTful API。将版本号放在URL中以是必需的。若是您有不兼容和破坏性的更改，版本号将让你能更容易的发布API。发布新API时，只需在增长版本号中的数字。这样的话，客户端能够自如的迁移到新API，不会因调用彻底不一样的新API而陷入困境。
使用直观的 “v” 前缀来表示后面的数字是版本号。

1. /v1/employees

你不须要使用次级版本号（“v1.2”），由于你不该该频繁的去发布API版本。

提供分页信息

一次性返回数据库全部资源不是一个好主意。所以，须要提供分页机制。一般使用数据库中众所周知的参数offset和limit。

1. /employees?offset=30&limit=15       #返回30 到 45的员工

若是客户端没有传这些参数，则应使用默认值。一般默认值是 offset=0和 limit=10。若是数据库检索很慢，应当减少 limit值。

1. /employees       #返回0 到 10的员工

此外，若是您使用分页，客户端须要知道资源总数。例： 请求：

1. GET /employees

响应：

1. {

2.  "offset": 0,

3.  "limit": 10,

4.  "total": 3465,

5.  "employees": [

6.    //...

7.  ]

8. }

非资源请求用动词

有时API调用并不涉及资源（如计算，翻译或转换）。例：

1. GET /translate?from=de_DE&to=en_US&text=Hallo

2. GET /calculate?para2=23&para2=432

在这种状况下，API响应不会返回任何资源。而是执行一个操做并将结果返回给客户端。所以，您应该在URL中使用动词而不是名词，来清楚的区分资源请求和非资源请求。

考虑特定资源搜索和跨资源搜索

提供对特定资源的搜索很容易。只需使用相应的资源集合URL，并将搜索字符串附加到查询参数中便可。

1. GET /employees?query=Paul

若是要对全部资源提供全局搜索，则须要用其余方法。前文提到，对于非资源请求URL，使用动词而不是名词。所以，您的搜索网址可能以下所示：

1. GET /search?query=Paul   //返回 employees, customers, suppliers 等等.

在响应参数中添加浏览其它API的连接

理想状况下，不会让客户端本身构造使用REST API的URL。让咱们思考一个例子。 客户端想要访问员工的薪酬表。为此，他必须知道他能够经过在员工URL（例如 /employees/21/salaryStatements）中附加字符串“salaryStatements”来访问薪酬表。这个字符串链接很容易出错，且难以维护。若是你更改了访问薪水表的REST API的方式（例如变成了 /employees/21/salary-statement或 /employees/21/paySlips），全部客户端都将中断。 更好的方案是在响应参数中添加一个 links字段，让客户端能够自动变动。
请求：

1. GET /employees/

响应：

1. //...

2.   {

3.      "id":1,

4.      "name":"Paul",

5.      "links": [

6.         {

7.            "rel": "salary",

8.            "href": "/employees/1/salaryStatements"

9.         }

10.      ]

11.   },

12. //...

若是客户端彻底依靠 links中的字段得到薪资表，你更改了API，客户端将始终得到一个有效的URL（只要你更改了 link字段，请求的URL会自动更改），不会中断。另外一个好处是，你的API变得能够自我描述，须要写的文档更少。
在分页时，您还能够添加获取下一页或上一页的连接示例。只需提供适当的偏移和限制的连接示例。

1. GET /employees?offset=20&limit=10

1. {

2.  "offset": 20,

3.  "limit": 10,

4.  "total": 3465,

5.  "employees": [

6.    //...

7.  ],

8.  "links": [

9.     {

10.        "rel": "nextPage",

11.        "href": "/employees?offset=30&limit=10"

12.     },

13.     {

14.        "rel": "previousPage",

15.        "href": "/employees?offset=10&limit=10"

16.     }

17.  ]

18. }