前言
RESTful是一种设计模式,或者说是一种设计规范,它并没有太多强制性的要求之类的,实际上它有的只是几个原则,当一个应用满足这些原则的时候,可以认为它是RESTful的。
这些规范的具体内容不再详述。RESTful可以认为是一种建立在HTTP协议之上的设计模式,充分的利用了HTTP协议的特定,使用URL来表示资源,用各个不同的HTTP动词来表示对资源的各种行为。
这样做的好处就是资源和操作分离,让资源的管理更加规范。
RESTful API一般采用OAuth 2.0协议来进行身份认证和访问权限控制,其中的资源就对应了OAuth中的资源服务器的资源。
URL格式设计
- 域名: 应该尽量将API部署在专用域名之下
1 | https://api.example.com |
- 版本:应该将API的版本号放入URL
1 | https://api.example.com/v1/ |
- 路径/端点: 表示API的具体地址
1 | GET /zoos:列出所有动物园 |
- 过滤条件
1 | ?limit=10:指定返回记录的数量 |
响应状态码
服务器向用户返回的状态码和提示信息,常见的有以下一些(方括号中是该状态码对应的HTTP动词)。
1 | 200 OK - [GET]:服务器成功返回用户请求的数据,该操作是幂等的(Idempotent)。 |
状态码的完全列表参见 https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
方法覆盖
有些客户端只能使用GET
和POST
这两种方法。服务器必须接受POST
模拟其他三个方法(PUT
、PATCH
、DELETE
)。
这时,客户端发出的 HTTP 请求,要加上X-HTTP-Method-Override
属性,告诉服务器应该使用哪一个动词,覆盖POST
方法。
1 | POST /api/Person/4 HTTP/1.1 |
上面代码中,X-HTTP-Method-Override
指定本次请求的方法是PUT
,而不是POST
。
HATEOAS
API 的使用者未必知道,URL 是怎么设计的。一个解决方法就是,在回应中,给出相关链接,便于下一步操作。这样的话,用户只要记住一个 URL,就可以发现其他的 URL。这种方法叫做 HATEOAS,这种API叫做Hypermedia API。Github的API就是这种设计,访问api.github.com会得到一个所有可用API的网址列表。