HTTP方法

最新推荐文章于 2022-11-01 19:15:34 发布

allway2

最新推荐文章于 2022-11-01 19:15:34 发布

阅读量804

点赞数

本文链接：https://blog.csdn.net/allway2/article/details/109538456

版权

REST API使您能够开发具有所有可能的CRUD（创建，检索，更新，删除）操作的任何类型的Web应用程序。REST指南建议在对服务器进行的特定类型的调用上使用特定的HTTP方法（尽管从技术上讲，有可能违反此指南，但强烈建议不要这样做）。

使用下面提供的信息来找到适合API执行的操作的HTTP方法。

HTTP GET

使用GET请求只能检索资源表示/信息，而不能以任何方式对其进行修改。由于GET请求不会更改资源状态，因此这些方法被称为安全方法。此外，GET API应该是幂等的，这意味着每次发出多个相同的请求都必须产生相同的结果，直到另一个API（POST或PUT）更改了服务器上资源的状态为止。

如果Request-URI涉及数据产生过程，则应将产生的数据作为响应中的实体返回，而不是过程的源文本，除非该文本恰好是过程的输出。

对于任何给定的HTTP GET API，如果在服务器上找到了资源，则它必须返回HTTP响应代码200 (OK)-以及响应正文，通常为XML或JSON内容（由于它们与平台无关的性质）。

如果在服务器上找不到资源，则它必须返回HTTP响应代码404 (NOT FOUND)。同样，如果确定GET请求本身的格式不正确，则服务器将返回HTTP响应代码400 (BAD REQUEST)。

示例请求URI

HTTP GET http://www.appdomain.com/users
HTTP GET http://www.appdomain.com/users?size=20&page=5
HTTP GET http://www.appdomain.com/users/123
HTTP GET http://www.appdomain.com/users/123/address

HTTP POST

使用POST API创建新的从属资源，例如，文件从属于包含该文件的目录，或者一行从属于数据库表。当严格按照REST进行交谈时，POST方法用于将新资源创建到资源集合中。

理想情况下，如果已在原始服务器上创建了资源，则响应应为HTTP响应代码，201 (Created)并包含描述请求状态并引用新资源的实体以及Location标头。

很多时候，POST方法执行的操作可能不会导致可以由URI标识的资源。在这种情况下，HTTP响应代码200 (OK)或204 (No Content)为适当的响应状态。

除非响应包含适当的Cache-Control或Expires标头字段，否则对此方法的响应不可缓存。

请注意，POST既不安全也不幂等，并且调用两个相同的POST请求将导致两个不同的资源包含相同的信息（资源ID除外）。

示例请求URI

HTTP POST http://www.appdomain.com/users
HTTP POST http://www.appdomain.com/users/123/accounts

HTTP PUT

主要使用PUT API更新现有资源（如果资源不存在，则API可能会决定是否创建新资源）。如果PUT API已创建新资源，则原始服务器务必通过HTTP响应代码201 (Created)响应通知用户代理，并且如果修改了现有资源，则应发送200 (OK)或204 (No Content）响应代码以指示请求已成功完成。

如果请求通过缓存，并且Request-URI标识一个或多个当前缓存的实体，则应将这些条目视为过期。此方法的响应不可缓存。

POST和PUT API之间的差异可以在请求URI中观察到。POST请求是在资源集合上进行的，而PUT请求是在单个资源上进行的。

示例请求URI

HTTP PUT http://www.appdomain.com/users/123
HTTP PUT http://www.appdomain.com/users/123/accounts/456

HTTP DELETE

顾名思义，DELETE API用于删除资源（由Request-URI标识）。

如果一个成功的DELETE请求响应应该是HTTP响应，code 200 (OK)如果该响应包括描述状态的实体，202 (Accepted)该动作已排队或204 (No Content)该动作已执行但该响应不包含实体。

DELETE操作是幂等的。如果删除资源，将从资源集合中将其删除。重复调用该资源上的DELETE API不会更改结果-但是，再次调用该资源上的DELETE将返回404（找不到），因为它已被删除。有人可能会说这使DELETE方法成为非幂等的。这是讨论和个人看法的问题。

如果请求通过缓存，并且Request-URI标识一个或多个当前缓存的实体，则应将这些条目视为过期。此方法的响应不可缓存。

示例请求URI

HTTP DELETE http://www.appdomain.com/users/123
HTTP DELETE http://www.appdomain.com/users/123/accounts/456

HTTP PATCH

HTTP PATCH请求将对资源进行部分更新。如果看到PUT请求还修改了资源实体，那么请更清楚地了解– PATCH方法是部分更新现有资源的正确选择，并且仅当要替换整个资源时才应使用PUT。

请注意，如果您决定在应用程序中使用PATCH API，则会遇到一些挑战：

在浏览器，服务器和Web应用程序框架中对PATCH的支持并不普遍。IE8，PHP，Tomcat，Django和许多其他软件对此缺少或损坏的支持。
PATCH请求的请求有效负载并不简单，因为它是针对PUT请求的。例如

HTTP GET /users/1

产生以下响应：

{id: 1, username: 'admin', email: 'email@example.org'}

更新电子邮件的示例补丁请求将如下所示：

HTTP PATCH /users/1

[
{ “op”: “replace”, “path”: “/email”, “value”: “new.email@example.org” }
]

根据HTTP规范，可能有以下可能的操作。

[
{ "op": "test", "path": "/a/b/c", "value": "foo" },
{ "op": "remove", "path": "/a/b/c" },
{ "op": "add", "path": "/a/b/c", "value": [ "foo", "bar" ] },
{ "op": "replace", "path": "/a/b/c", "value": 42 },
{ "op": "move", "from": "/a/b/c", "path": "/a/b/d" },
{ "op": "copy", "from": "/a/b/d", "path": "/a/b/e" }
]

PATCH方法不能替代POST或PUT方法。它应用增量（diff）而不是替换整个资源。

RESTful API的HTTP方法摘要

下表总结了上面讨论的HTTP方法的使用。

HTTP方法	CRUD	整个集合（例如/USERS）	特定项目（例如/USERS/123）
POST	创建	201（已创建），“位置”标头，带有指向 /users/{id} 的链接，其中包含新ID。	避免在单个资源上使用POST
GET	读	200（确定），用户列表。使用分页，排序和过滤来浏览大列表。	200（确定），单用户。404（未找到），如果未找到ID或无效。
PUT	更新/替换	405（不允许使用方法），除非您要更新整个资源集合中的每个资源。	200（确定）或204（无内容）。如果找不到ID或无效，请使用404（未找到）。
PATCH	部分更新/修改	405（不允许使用方法），除非您要修改集合本身。	200（确定）或204（无内容）。如果找不到ID或无效，请使用404（未找到）。
DELETE	删除	405（不允许使用方法），除非您要删除整个集合，请谨慎使用。	200（确定）。404（未找到），如果未找到ID或无效。