1、RESTful 是什么
一套结构清晰、符合标准、易于理解、扩展方便让大部分人都能够理解接受的接口风格。
2、RESTful 解决什么问题
- 统一前后端分离场景下接口设计风格。因为定义所说。
- 通过http方法解决项目url爆炸问题。不太重要。
3、RESTful url格式
我们在设计API时URL的path是需要认真考虑的，而RESTful对path的设计做了一些规范，通常一个RESTful API的path组成如下：
/{version}/{resources}/{resource_id}
version：API版本号，有些版本号放置在头信息中也可以，通过控制版本号有利于应用迭代。
resources：资源，RESTful API推荐用小写英文单词的复数形式。
resource_id：资源的id，访问或操作该资源。
当然，有时候可能资源级别较大，其下还可细分很多子资源也可以灵活设计URL的path（不建议，不好理解和扩展）例如：
/{version}/{resources}/{resource_id}/{subresources}/{subresource_id}
resources 和 subresources 之间是有层级关系的
从大体样式了解URL路径组成之后，对于RESTful API的URL具体设计的规范如下：
- 不用大写字母，所有单词使用英文且小写。
- 连字符用中杠
"-"而不用下杠"_" - 正确使用
"/"表示层级关系,URL的层级不要过深，并且越靠前的层级应该相对越稳定 - 结尾不要包含正斜杠分隔符
"/" - URL中不出现动词，用请求方式表示动作
- 资源表示用复数不要用单数
- 不要使用文件扩展名
4、动词 + 宾语
RESTful 的核心思想就是，客户端发出的数据操作指令都是"动词 + 宾语"的结构。比如，GET /products 这个命令，GET 是动词，/products 是宾语。
动词通常就是如下五种 HTTP 方法，对应 CRUD 操作。
GET- 检索位于指定 URI 处的资源的表示形式。响应消息的正文包含所请求资源的详细信息。POST- 在指定的 URI 处创建新资源。请求消息的正文将提供新资源的详细信息。请注意，POST 还用于触发不实际创建资源的操作，如登录、注销等。PUT- 在指定的 URI 处创建或替换资源。请求消息的正文指定要创建或更新的资源。PATCH- 对资源执行部分更新。请求正文包含要应用到资源的一组更改。DELETE- 删除位于指定 URI 处的资源。
根据 HTTP 规范，动词一律大写。
5、状态码
我们首先要正确使用各类状态码来表示该请求的处理执行结果。状态码主要分为五大类：
1xx：相关信息
2xx：操作成功
3xx：重定向
4xx：客户端错误
5xx：服务器错误
每一大类有若干小类，状态码的种类比较多，而主要常用状态码罗列在下面：
200 OK - [GET]：服务器成功返回用户请求的数据，该操作是幂等的（Idempotent）。
201 CREATED - [POST/PUT/PATCH]：用户新建或修改数据成功。
202 Accepted - [*]：表示一个请求已经进入后台排队（异步任务）
204 NO CONTENT - [DELETE]：用户删除数据成功。
400 INVALID REQUEST - [POST/PUT/PATCH]：用户发出的请求有错误，服务器没有进行新建或修改数据的操作，该操作是幂等的。
401 Unauthorized - [*]：表示用户没有权限（令牌、用户名、密码错误）。
403 Forbidden - [*] 表示用户得到授权（与401错误相对），但是访问是被禁止的。
404 NOT FOUND - [*]：用户发出的请求针对的是不存在的记录，服务器没有进行操作，该操作是幂等的。
406 Not Acceptable - [GET]：用户请求的格式不可得（比如用户请求JSON格式，但是只有XML格式）。
410 Gone -[GET]：用户请求的资源被永久删除，且不会再得到的。
422 Unprocesable entity - [POST/PUT/PATCH] 当创建一个对象时，发生一个验证错误。
500 INTERNAL SERVER ERROR - [*]：服务器发生错误，用户将无法判断发出的请求是否成功。
6、例子：
7、参考
一文搞懂RESTful API
REST API 简介
RESTful API 那些不为人知的秘密 | 架构 | 万维网 | Richardson 成熟度模型
Restful API 接口规范详解
