一、参考资料
二、我的笔记
RESTful是一种API设计规范，用于Web数据接口的设计。
这篇文章的主要内容包括：
1.URL设计
- 动词+宾语。RESTful的核心思想是，客户端发出的数据操作指令都是"动词+宾语"的结构，如GET /articles。
- 动词的覆盖。有些客户端只能使用GET和POST，服务器必须接受使用POST模拟其他方法(通过X-HTTP-Method-Override属性)。
- 宾语必须是名词。
- 使用复数URL，如GET /articles/2。
- 避免多级URL。资源需要多级分类，如获取某个作者的某一类文章时，写成GET /authors/12/categories/2不利于扩展，语义也不明确。更好的做法是，除了第一级，其他都用查询字符串表达，如GET /authors/12?categories=2。
2. 状态码
状态码必须精确。状态码有以下几大类：
| 状态码 | 含义 |
|---|---|
| 1xx | 相关信息 |
| 2xx | 操作成功 |
| 3xx | 重定向 |
| 4xx | 客户端错误 |
| 5xx | 服务器错误 |
这几大类里面共包含100多种状态码。常用的有：
| 状态码 | 含义 |
|---|---|
| 200 | OK |
| 201 | POST成功创建了资源 |
| 202 | 服务器接收了请求，但之后再处理(异步) |
| 400 | Bad Request |
| 401 | Unauthorized |
| 404 | 请求的资源不存在 |
| 500 | 服务器内部错误 |
3. 应答
- 返回JSON，而不是纯文本，这样才能返回标准的结构化数据。
- 发生错误时，不要一律返回200状态码(把错误信息放在数据体里面)。
- 在应答中提供链接(HATEOAS)。比如访问https://api.github.com/：
{
"current_user_url": "https://api.github.com/user",
"current_user_authorizations_html_url": "https://github.com/settings/connections/applications{/client_id}",
"authorizations_url": "https://api.github.com/authorizations",
"code_search_url": "https://api.github.com/search/code?q={query}{&page,per_page,sort,order}",
"commit_search_url": "https://api.github.com/search/commits?q={query}{&page,per_page,sort,order}",
...
}用户只要记住一个URL，就可以发现其他URL。
