REST API-为什么使用 PUT DELETE POST GET？

因此，我浏览了一些关于创建 RESTAPI 的文章。 其中一些建议使用所有类型的 HTTP 请求: 如 PUT DELETE POST GET。 我们将创建一个例子 Index.php，并以这种方式编写 API:

$method = $_SERVER['REQUEST_METHOD'];
$request = split("/", substr(@$_SERVER['PATH_INFO'], 1));


switch ($method) {
case 'PUT':
....some put action....
break;
case 'POST':
....some post action....
break;
case 'GET':
....some get action....
break;
case 'DELETE':
....some delete action....
break;
}

好吧，我承认——我还不太了解 Web 服务。 但是，通过常规的 POST或 GET(包含方法名和所有参数)接受 JSON对象，然后在 JSON 进行响应不是更容易一些吗。我们可以通过 PHP 的 json_encode()和 json_decode()轻松地序列化/反序列化，并且不需要处理不同的 HTTP 请求方法就可以对该数据进行任何处理。

我错过了什么吗？

更新1:

好的-通过挖掘各种 API，学习了很多关于 XML-RPC，JSON-RPC，SOAP，休息的知识之后，我得出了一个结论，这种类型的 API 是合理的。实际上，堆栈交换在他们的站点上大多使用这种方法，我认为这些人知道他们在做什么 堆栈交换 API。

127015 次浏览
小开

这是一个安全性和可维护性的问题。

安全的方法

只要有可能，您应该使用“安全”(单向)方法，如 GET 和 HEAD，以限制潜在的漏洞。

幂等方法幂等方法

只要有可能，就应该使用“幂等”方法，如 GET、 HEAD、 PUT 和 DELETE，这些方法不会产生副作用，因此不容易出错/更容易控制。

来源

小开

你问:

通过普通的 $_ POST 接受 JSON 对象然后在 JSON 进行响应不是更简单吗

来自 休息的维基百科:

RESTful 应用程序最大限度地利用预先存在的、定义良好的接口和所选网络协议提供的其他内置功能，并尽量减少在其上添加新的特定于应用程序的特性

从我所看到的(很少)来看，我相信这通常是通过最大限度地使用现有的 HTTP 动词，并为您的服务设计一个尽可能强大和不言而喻的 URL 方案来实现的。

不鼓励使用自定义数据协议(即使它们构建在标准协议(如 SOAP 或 JSON)之上) ，并且应该最小化，以便最好地遵循 REST 思想。

另一方面，HTTP 上的 SOAP RPC 鼓励每个应用程序设计人员定义一个新的和任意的名词和动词词汇表(例如 getUsers () ，savePurchaseOrder (...)) ，通常覆盖在 HTTP‘ POST’动词上。这忽略了 HTTP 的许多现有功能，比如身份验证、缓存和内容类型协商，并且可能使应用程序设计人员在新词汇表中重新创建许多这些特性。

实际使用的对象可以采用任何格式。其思想是尽可能多地重用 HTTP，以公开用户希望对这些资源执行的操作(查询、状态管理/变异、删除)。

你问:

我错过了什么吗？

关于 REST 和 URI 语法/HTTP 动词本身还有很多需要了解的。例如，有些动词是幂等的，有些不是。我在你的问题中没有看到任何关于这方面的内容，所以我没有费心去深入探讨。其他的答案和维基百科都有很多好的信息。

此外，如果您使用的是真正的静态 API，那么还有很多关于构建在 HTTP 之上的各种网络技术的知识可以利用。我会从认证开始。

小开
最佳答案

RE表示式 是的tate T传输的想法并不是以尽可能简单的方式访问数据。

您建议使用发布请求来访问 JSON，这是访问/操作数据的完美有效方法。

REST 是一种用于 有意义访问数据的方法。当您在 REST 中看到一个请求时，它应该立即显示数据发生了什么。

例如:

GET: /cars/make/chevrolet

可能会返回一份雪佛兰汽车的名单

在考虑了一下如何合理地将数据类型化合并到 REST API 之后，我得出结论，显式地指定数据类型的最佳方法是通过已经存在的文件扩展名，如 .js、 .json、 .html或 .xml。缺少的文件扩展名将默认为缺省格式(如 JSON) ; 不支持的文件扩展名可能返回 501 Not Implemented状态码。

另一个例子:

POST: /cars/
{ make:chevrolet, model:malibu, colors:[red, green, blue, grey] }

可能会创建一个新的雪佛兰 Malibu 在数据库与相关的颜色。我说 很有可能是因为 REST api 不需要与数据库结构直接相关。它只是一个屏蔽接口，以保护真正的数据(就像数据库结构的访问器和变异器一样)。

现在我们需要谈谈 阳痿的问题。通常 REST 通过 HTTP 实现 讨厌。HTTP 对请求使用 GET、 PUT、 POST和 DELETE。

REST 可以的一个非常简单的实现使用以下 CRUD 映射:

Create -> Post
Read   -> Get
Update -> Put
Delete -> Delete

这个实现有一个问题: Post 被定义为一个非幂等的方法。这意味着同一 Post 方法的后续调用将导致 与众不同服务器状态。Get、 Put 和 Delete 是幂等的; 这意味着多次调用它们应该会导致相同的服务器状态。

这意味着诸如:

Delete: /cars/oldest

实际上可以作为:

Post: /cars/oldest?action=delete

然而呢

Delete: /cars/id/123456

将导致相同的服务器状态，如果您调用它一次，或如果您调用它1000次。

移除 oldest项目的更好办法是请求:

Get: /cars/oldest

并使用所得数据中的 ID发出 delete请求:

Delete: /cars/id/[oldest id]

这种方法的一个问题是，如果在请求 /oldest和发出 delete之间添加了另一个 /cars项目。

小开

简而言之，REST 强调名词胜过动词。随着 API 变得越来越复杂，添加的东西就越来越多，而不是命令越来越多。

小开

关于使用扩展定义数据类型。 我注意到 MailChimp API 正在这样做，但我不认为这是一个好主意。

GET /zzz/cars.json/1


GET /zzz/cars.xml/1

我的想法听起来不错，但我认为“旧”方法更好——使用 HTTP 头

GET /xxx/cars/1
Accept: application/json

此外，HTTP 头对于跨数据类型的通信(如果有人需要的话)更好

POST /zzz/cars
Content-Type: application/xml     <--- indicates we sent XML to server
Accept: application/json          <--- indicates we want get data back in JSON format
小开

我错过了什么吗？

是的

这种现象的存在是因为 统一接口约束统一接口约束。REST 喜欢使用已经存在的标准，而不是重造轮子。HTTP 标准已经被证明是高度可伸缩的(web 已经工作了一段时间)。我们为什么要修一个没坏的东西? ！

注意: 如果希望将客户机与服务解耦，统一接口约束非常重要。这类似于为类定义接口，以便将它们彼此分离。办公室。在这里，统一的接口由 HTTP、 MIME 类型、 URI、 RDF、 链接数据词汇表、 九头蛇词汇等标准组成。.

小开

良好的语义在编程中很重要。

除了 GET/POST 之外，使用更多的方法将是有帮助的，因为它将增加代码的可读性，并使其更容易维护。

为什么？

因为您知道 GET 将从 API 中检索数据。您知道 POST 将向您的系统添加新数据。您知道 PUT 将进行更新。删除将删除行等等,

我通常结构化我的 RESTFULWeb 服务，这样我就有一个函数回调，名称与方法相同。

我使用 PHP，所以我使用 function _ vis (我认为它的名称)。如果函数不存在，则抛出405(方法不允许)。

小开

Bill Venners: 在你题为“为什么 REST 失败”的博客文章中，你说我们需要所有四个 HTTP 动词ー GET、 POST、 PUT 和 DELETE ー并且哀叹浏览器供应商只有 GET 和 POST为什么我们需要这四个动词？为什么 GET 和 POST 还不够？

Elliotte Rusty Harold: HTTP 中有四种基本方法: GET、 POST、 PUT 和 DELETE。GET 在大多数情况下被使用。它用于任何安全的，不会引起任何副作用的东西。GET 可以通过代理服务器进行书签、缓存、链接和传递。这是一个非常强大的操作，一个非常有用的操作。

相比之下，POST 可能是最强大的操作。它无所不能。对于可能发生的事情是没有限制的，因此，你必须非常小心。你没有加入书签。你不能缓存它。你不能提前取出来。在不询问用户的情况下，您不能对 POST 执行任何操作。你想这么做吗？如果用户按下按钮，您可以发布一些内容。但是你不会看着一个页面上的所有按钮，然后开始随机地按下它们。相比之下，浏览器可能会查看页面上的所有链接并预先获取它们，或者预先获取它们认为接下来最有可能被关注的链接。事实上，一些浏览器、 Firefox 扩展和其他各种工具曾经尝试过这样做。

PUT 和 DELETE 位于 GET 和 POST 之间。PUT 或 DELETE 与 POST 之间的区别在于 PUT 和 DELETE 是 * 幂等的，而 POST 不是。如果需要，可以重复 PUT 和 DELETE。假设您试图将一个新页面上传到一个站点。假设您想在 http://www.example.com/foo.html创建一个新页面，那么您输入您的内容并将其放在该 URL 处。服务器在您提供的 URL 处创建该页面。现在，让我们假设由于某种原因您的网络连接中断了。你不确定，请求通过了吗？也许是网速太慢。也许是代理服务器出了问题。所以再试一次完全没问题，或者再试一次ーー想试多少次就试多少次。因为把同一个文档放在同一个 URL 上十次和放一次没什么区别。对于 DELETE 也是如此。你可以删除一些东西十次，这与删除一次是一样的。

相比之下，POST 可能每次都会导致不同的事情发生。假设你正在通过按下购买按钮结账离开一家网上商店。如果您再次发送 POST 请求，您可能会第二次购买购物车中的所有商品。如果你再寄一次，你已经买了三次了。这就是为什么浏览器在没有用户明确同意的情况下重复 POST 操作时必须非常小心的原因，因为如果重复两次 POST 操作可能会导致两件事情的发生，如果重复三次 POST 操作可能会导致三件事情的发生。对于 PUT 和 DELETE，零个请求和一个请求之间有很大区别，但是一个请求和十个请求之间没有区别。

请访问网址以获取更多信息。 < a href = “ http://www.artima.com/lejava/article/why _ put _ and _ delete te.html”rel = “ nofollow noReferrer”> http://www.artima.com/lejava/articles/why_put_and_delete.html

更新:

幂等方法 等幂 HTTP 方法是一种可以多次调用而没有不同结果的 HTTP 方法。如果只调用该方法一次，或者调用十次以上，都没有关系。结果应该是一样的。同样，这只适用于结果，而不是资源本身。这仍然可以进行操作(如更新时间戳，前提是此信息不在(当前)资源表示中共享。

考虑以下例子:

A = 4;

A + + ;

第一个例子是幂等的: 无论我们执行这个语句多少次，a 始终是4。第二个例子不是幂等的。执行这10次将导致一个不同的结果时，运行5次。由于这两个示例都在改变 a 的值，因此它们都是不安全的方法。

小开

基本上 REST 是(维基百科) :

  1. 客户机-服务器架构
  2. 无国籍状态
  3. 易存取性
  4. 分层系统
  5. 按需编码(可选)
  6. 统一界面

REST 不是协议，它是原则。 不同的尿液和方法，所谓的最佳实践。


提交答案