REST RESTful API 详解
REST RESTful API 详解
什么是REST
REST是 REpresentational State Transfer 的缩写,它是分布式超媒体系统的架构风格,最初由Roy Fielding在2000年的着名论文中提出的。
与任何其他架构风格一样,REST也有自己的6个引导约束,如果接口需要被称为RESTful,则必须满足这些约束。这些原则如下。
REST的指导原则
- 客户端 - 服务器 - 通过将用户界面问题与数据存储问题分开,我们提高了跨多个平台的用户界面的可移植性,并通过简化服务器组件来提高可扩展性。
- 无状态 - 从客户端到服务器的每个请求都必须包含理解请求所需的所有信息,并且不能利用服务器上任何存储的上下文。因此,会话状态完全保留在客户端上。
- 可缓存 - 缓存约束要求将对请求的响应中的数据隐式或显式标记为可缓存或不可缓存。如果响应是可缓存的,则客户端缓存有权重用该响应数据以用于以后的等效请求。
- 统一接口 - 通过将通用性的软件工程原理应用于组件接口,简化了整个系统架构,提高了交互的可见性。为了获得统一的接口,需要多个架构约束来指导组件的行为。REST由四个接口约束定义:资源识别; 通过陈述来处理资源; 自我描述性的信息; 并且,超媒体作为应用程序状态的引擎。
- 分层系统 - 分层系统风格允许通过约束组件行为来使体系结构由分层层组成,这样每个组件都不能“看到”超出与它们交互的直接层。
- 按需代码(可选) - REST允许通过以小程序或脚本的形式下载和执行代码来扩展客户端功能。这通过减少预先实现所需的功能数量来简化客户端。
资源
REST中信息的关键抽象是一种资源。可以命名的任何信息可以是资源:文档或图像,临时服务,其他资源的集合,非虚拟对象(例如,人)等。REST使用资源标识符来标识组件之间交互中涉及的特定资源。
任何特定时间戳的资源状态称为资源表示。表示由数据,描述数据的元数据和超媒体链接组成,这些链接可以帮助客户转换到下一个期望的状态。
表示的数据格式称为媒体类型。媒体类型标识定义如何处理表示的规范。真正的RESTful API看起来像超文本。每个可寻址信息单元明确地(例如,链接和id属性)或隐式地(例如,从媒体类型定义和表示结构导出)携带地址。
根据罗伊菲尔丁的说法:
超文本(或超媒体)意味着信息和控制的同时呈现,使得信息成为用户(或自动机)通过其获得选择和选择动作的可供性。
请记住,超文本不需要是浏览器上的HTML(或XML或JSON)。机器在了解数据格式和关系类型时可以跟踪链接。
此外,资源表示应该是自描述的:客户端不需要知道资源是员工还是设备。它应该基于与资源相关的媒体类型。
因此在实践中,您最终会创建大量自定义媒体类型 - 通常是与一种资源相关联的一种媒体类型。
每种媒体类型都定义了默认处理模型。例如,HTML定义了超文本的呈现过程以及每个元素周围的浏览器行为。
它与资源方法GET / PUT / POST / DELETE / ...没有任何关系,除了一些媒体类型元素将定义一个过程模型。
其类似于“具有href属性的锚元素创建一个超文本链接,当被选中时,在与CDATA编码的href属性对应的URI上调用检索请求(GET)。
资源方法
与REST相关的其他重要事项是用于执行所需转换的资源方法。许多人错误地将资源方法与HTTP GET / PUT / POST / DELETE方法联系起来。
Roy Fielding从未提及任何关于在哪种情况下使用哪种方法的建议。他强调的是它应该是统一的界面。如果你决定HTTP POST将用于更新资源 - 而不是大多数人推荐HTTP PUT - 它没关系,应用程序界面将是RESTful。
理想情况下,更改资源状态所需的所有内容都应该是该资源的API响应的一部分 - 包括方法以及它们将保留表示的状态。
应输入REST API,除了初始URI(书签)和适用于目标受众的标准化媒体类型集之外没有任何先验知识(即,任何可能使用API的客户都应该理解)。
从那时起,所有应用程序状态转换必须由客户端选择服务器提供的选择来驱动,这些选择存在于接收的表示中或者由用户对这些表示的操纵所暗示。
转换可以由客户端对媒体类型和资源通信机制的知识来确定(或限制),这两者都可以在运行中(例如,按需代码)进行改进。
[失败在这里意味着带外信息正在推动交互,而不是超文本。
在构建RESTful API时,另一件可以帮助你的是基于查询的API结果应该由带有摘要信息的链接列表表示,而不是由原始资源表示的数组表示,因为查询不能替代资源标识。
REST和HTTP不一样!!
很多人更喜欢将HTTP与REST进行比较。REST和HTTP不一样。
虽然,因为REST还打算使web(互联网)更加简化和标准化,他主张更严格地使用REST原则。这就是人们试图开始将REST与网络(HTTP)进行比较的地方。Roy fielding在他的论文中没有提到任何实现指令 - 包括任何协议首选项和HTTP。到时候,您正在遵循REST的6个指导原则,您可以将您的界面称为RESTful。
简而言之,在REST架构风格中,数据和功能被视为资源,并使用统一资源标识符(URI)进行访问。通过使用一组简单,定义明确的操作来处理资源。客户端和服务器通过使用标准化接口和协议(通常是HTTP)来交换资源的表示。
资源与其表示分离,以便可以以各种格式访问其内容,例如HTML,XML,纯文本,PDF,JPEG,JSON等。例如,可以使用和使用关于资源的元数据来控制高速缓存,检测传输错误,协商适当的表示格式,以及执行认证或访问控制。最重要的是,与资源的每次交互都是无状态的。
所有这些原则都有助于RESTful应用程序简单,轻便,快速。
REST架构约束
REST代表Re presentational S tate T ransfer,这是Roy Fielding在2000年创造的一个术语。它是一种用于通过HTTP设计松散耦合应用程序的架构风格,通常用于Web服务的开发。REST没有强制执行任何有关如何在较低级别实现它的规则,它只是提出了高级设计指南,让您考虑自己的实现。
REST资源命名
使用名词来表示资源
RESTful URI应该引用作为事物(名词)的资源而不是引用动作(动词),因为名词具有动词不具有的属性 - 类似于具有属性的资源。
动词 + 宾语
ESTful 的核心思想就是,客户端发出的数据操作指令都是"动词 + 宾语"的结构。比如,GET /users
这个命令,GET
是动词,/users
是宾语。
- GET:读取(Read)
- POST:新建(Create)
- PUT:更新(Update)
- PATCH:更新(Update),通常是部分更新
- DELETE:删除(Delete)
动词的覆盖
有些客户端只能使用GET
和POST
这两种方法。服务器必须接受POST
模拟其他三个方法(PUT
、PATCH
、DELETE
)。
这时,客户端发出的 HTTP 请求,要加上X-HTTP-Method-Override
属性,告诉服务器应该使用哪一个动词,覆盖POST
方法。即
POST /api/Person/4 HTTP/1.1 X-HTTP-Method-Override: PUT
上面代码中,X-HTTP-Method-Override
指定本次请求的方法是PUT
,而不是POST
。
宾语必须是名词
宾语就是 API 的 URL,是 HTTP 动词作用的对象。它应该是名词,不能是动词。比如,/uses
这个 URL 就是正确的,而下面的 URL 不是名词,所以都是错误的。
- /getAllCars
- /createNewCar
- /deleteAllRedCars
复数 URL
既然 URL 是名词,那么应该使用复数,还是单数?
这没有统一的规定,但是常见的操作是读取一个集合,比如GET /users
(读取所有文章),这里明显应该是复数。
为了统一起见,建议都使用复数 URL,比如GET /users/2
要好于GET /user/2
。
使用连字符( - )来提高URI的可读性
要使您的URI易于扫描和解释,请使用连字符( - )字符来提高长路径段中名称的可读性。
http://api.example.com/inventory-management/managed-entities/{id}/install-script-location //更易读 http://api.example.com/inventory-management/managedEntities/{id}/installScriptLocation //不太可读
不要使用下划线(_)
http://api.example.com/inventory-management/managed-entities/{id}/install-script-location //更易读 http://api.example.com/inventory_management/managed_entities/{id}/install_script_location //更容易出错
在URI中使用小写字母
方便时,URI路径中应始终首选小写字母。
http://api.example.org/my-folder/my-doc // 1 HTTP://API.EXAMPLE.ORG/my-folder/my-doc // 2 http://api.example.org/My-Folder/my-doc // 3
在上面的例子中,1和2是相同的,但3不是因为它使用大写字母的My-Folder。
不要使用文件扩展名
文件扩展名看起来很糟糕,不会增加任何优势。删除它们也会减少URI的长度。没理由保留它们。
除了上述原因,如果您想使用文件扩展突出显示API的媒体类型,那么您应该依赖于通过Content-Type
标题传达的媒体类型来确定如何处理正文的内容。
http://api.example.com/device-management/managed-devices.xml / *不要使用它* / http://api.example.com/device-management/managed-devices / *这是正确的URI * /
永远不要在URI中使用CRUD函数名称
URI不应用于指示执行CRUD功能。URI应该用于唯一标识资源,而不是对它们的任何操作。应使用HTTP请求方法来指示执行哪个CRUD功能。
使用查询组件过滤URI集合
很多时候,您会遇到需要根据某些特定资源属性对需要排序,过滤或限制的资源集合的要求。
为此,请不要创建新的API - 而是在资源集合API中启用排序,过滤和分页功能,并将输入参数作为查询参数传递。例如:
ttp://api.example.com/device-management/managed-devices http://api.example.com/device-management/managed-devices?region=USA http://api.example.com/device-management/managed-devices?region=USA&brand=XYZ http://api.example.com/device-management/managed-devices?region=USA&brand=XYZ&sort=installation-date
注意状态代码
状态码必须精确
客户端的每一次请求,服务器都必须给出回应。回应包括 HTTP 状态码和数据两部分。
HTTP 状态码就是一个三位数,分成五个类别。
1xx:相关信息
2xx:操作成功
3xx:重定向
4xx:客户端错误
5xx:服务器错误
这五大类总共包含100多种状态码,覆盖了绝大部分可能遇到的情况。每一种状态码都有标准的(或者约定的)解释,客户端只需查看状态码,就可以判断出发生了什么情况,所以服务器应该返回尽可能精确的状态码。
API 不需要1xx
状态码,下面介绍其他四类状态码的精确含义。
HTTP状态码列表:https://en.wikipedia.org/wiki/List_of_HTTP_status_codes
2xx 状态码
200
状态码表示操作成功,但是不同的方法可以返回更精确的状态码。
GET: 200 OK POST: 201 Created PUT: 200 OK PATCH: 200 OK DELETE: 204 No Content
上面代码中,POST
返回201
状态码,表示生成了新的资源;DELETE
返回204
状态码,表示资源已经不存在。
此外,202 Accepted
状态码表示服务器已经收到请求,但还未进行处理,会在未来再处理,通常用于异步操作。下面是一个例子。
HTTP/1.1 202 Accepted { "task": { "href": "/api/company/job-management/jobs/2130040", "id": "2130040" } }
3xx 状态码
API 用不到301
状态码(永久重定向)和302
状态码(暂时重定向,307
也是这个含义),因为它们可以由应用级别返回,浏览器会直接跳转,API 级别可以不考虑这两种情况。
API 用到的3xx
状态码,主要是303 See Other
,表示参考另一个 URL。它与302
和307
的含义一样,也是"暂时重定向",区别在于302
和307
用于GET
请求,而303
用于POST
、PUT
和DELETE
请求。收到303
以后,浏览器不会自动跳转,而会让用户自己决定下一步怎么办。下面是一个例子。
HTTP/1.1 303 See Other Location: /api/orders/12345
4xx 状态码
4xx
状态码表示客户端错误,主要有下面几种。
400 Bad Request
:服务器不理解客户端的请求,未做任何处理。
401 Unauthorized
:用户未提供身份验证凭据,或者没有通过身份验证。
403 Forbidden
:用户通过了身份验证,但是不具有访问资源所需的权限。
404 Not Found
:所请求的资源不存在,或不可用。
405 Method Not Allowed
:用户已经通过身份验证,但是所用的 HTTP 方法不在他的权限之内。
410 Gone
:所请求的资源已从这个地址转移,不再可用。
415 Unsupported Media Type
:客户端要求的返回格式不支持。比如,API 只能返回 JSON 格式,但是客户端要求返回 XML 格式。
422 Unprocessable Entity
:客户端上传的附件无法处理,导致请求失败。
429 Too Many Requests
:客户端的请求次数超过限额。
5xx 状态码
5xx
状态码表示服务端错误。一般来说,API 不会向用户透露服务器的详细信息,所以只要两个状态码就够了。
500 Internal Server Error
:客户端请求有效,服务器处理时发生了意外。
503 Service Unavailable
:服务器无法处理请求,一般用于网站维护状态。
服务器的回应类型
1、不要返回纯本文
API 返回的数据格式,不应该是纯文本,而应该是一个 JSON 对象,因为这样才能返回标准的结构化数据。所以,服务器回应的 HTTP 头的Content-Type
属性要设为application/json
。
客户端请求时,也要明确告诉服务器,可以接受 JSON 格式,即请求的 HTTP 头的ACCEPT
属性也要设成application/json
。下面是一个例子。
GET /orders/2 HTTP/1.1 Accept: application/json
2、发生错误时,不要返回 200 状态码
有一种不恰当的做法是,即使发生错误,也返回200
状态码,把错误信息放在数据体里面,就像下面这样。
HTTP/1.1 200 OK Content-Type: application/json { "status": false, "data": { "error": "Expected at least two items in list." } }
上面代码中,解析数据体以后,才能得知操作失败。
这种做法实际上取消了状态码,这是完全不可取的。正确的做法是,状态码反映发生的错误,具体的错误信息放在数据体里面返回。下面是一个例子。
HTTP/1.1 400 Bad Request Content-Type: application/json { "error": "Invalid payoad.", "detail": { "surname": "This field is required." } }
3、提供链接
API 的使用者未必知道,URL 是怎么设计的。一个解决方法就是,在回应中,给出相关链接,便于下一步操作。这样的话,用户只要记住一个 URL,就可以发现其他的 URL。这种方法叫做 HATEOAS。
举例来说,GitHub 的 API 都在 api.github.com 这个域名。访问它,就可以得到其他 URL。
{ "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}", "emails_url": "https://api.github.com/user/emails", "emojis_url": "https://api.github.com/emojis", "events_url": "https://api.github.com/events", "feeds_url": "https://api.github.com/feeds", "followers_url": "https://api.github.com/user/followers", "following_url": "https://api.github.com/user/following{/target}", "gists_url": "https://api.github.com/gists{/gist_id}", "hub_url": "https://api.github.com/hub", "issue_search_url": "https://api.github.com/search/issues?q={query}{&page,per_page,sort,order}", "issues_url": "https://api.github.com/issues", "keys_url": "https://api.github.com/user/keys", "notifications_url": "https://api.github.com/notifications", "organization_repositories_url": "https://api.github.com/orgs/{org}/repos{?type,page,per_page,sort}", "organization_url": "https://api.github.com/orgs/{org}", "public_gists_url": "https://api.github.com/gists/public", "rate_limit_url": "https://api.github.com/rate_limit", "repository_url": "https://api.github.com/repos/{owner}/{repo}", "repository_search_url": "https://api.github.com/search/repositories?q={query}{&page,per_page,sort,order}", "current_user_repositories_url": "https://api.github.com/user/repos{?type,page,per_page,sort}", "starred_url": "https://api.github.com/user/starred{/owner}{/repo}", "starred_gists_url": "https://api.github.com/gists/starred", "team_url": "https://api.github.com/teams", "user_url": "https://api.github.com/users/{user}", "user_organizations_url": "https://api.github.com/user/orgs", "user_repositories_url": "https://api.github.com/users/{user}/repos{?type,page,per_page,sort}", "user_search_url": "https://api.github.com/search/users?q={query}{&page,per_page,sort,order}" }
参考文献:
- RESTful API Design: 13 Best Practices to Make Your Users Happy, by Florimond Manca
- API design, by MicroSoft Azure