REST API - 为什么使用 PUT DELETE POST GET? [英] REST API - why use PUT DELETE POST GET?

问题描述

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

So, I was looking through some articles on creating REST API's. And some of them suggest using all types of HTTP requests: like PUT DELETE POST GET. We would create for example index.php and write API this way:

$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 请求方法.

OK, granted - I don't know much about web services (yet). But, wouldn't it be easier to just accept JSON object through regular POST or GET (that would contain method name and all parameters) and then respond in JSON as well. We can easily serialize/deserialize via PHP's json_encode() and json_decode() and do whatever we want with that data without having to deal with different HTTP request methods.

我错过了什么吗?

更新 1:

好的 - 在深入研究了各种 API 并学习了很多关于 XML-RPC、JSON-RPC、SOAP、REST 之后 我得出的结论是这种类型的 API 是合理的.实际上，堆栈交换在他们的网站上几乎使用这种方法，我确实认为这些人知道他们在做什么 堆栈交换 API.

Ok - after digging through various API's and learning a lot about XML-RPC, JSON-RPC, SOAP, REST I came to a conclusion that this type of API is sound. Actually stack exchange is pretty much using this approach on their sites and I do think that these people know what they are doing Stack Exchange API.

推荐答案

REpresentational State Transfer 的想法不是关于以最简单的方式访问数据.

The idea of REpresentational State Transfer is not about accessing data in the simplest way possible.

您建议使用 post 请求来访问 JSON，这是访问/操作数据的一种非常有效的方式.

You suggested using post requests to access JSON, which is a perfectly valid way to access/manipulate data.

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

REST is a methodology for meaningful access of data. When you see a request in REST, it should immediately be apparant what is happening with the data.

例如:

GET: /cars/make/chevrolet

很可能会返回雪佛兰汽车的列表.一个好的 REST api 甚至可能在查询字符串中加入一些输出选项，比如 ?output=json 或 ?output=html 这将允许访问者决定什么格式信息应该被编码.

is likely going to return a list of chevy cars. A good REST api might even incorporate some output options in the querystring like ?output=json or ?output=html which would allow the accessor to decide what format the information should be encoded in.

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

After a bit of thinking about how to reasonably incorporate data typing into a REST API, I've concluded that the best way to specify the type of data explicitly would be via the already existing file extension such as .js, .json, .html, or .xml. A missing file extension would default to whatever format is default (such as JSON); a file extension that's not supported could return a 501 Not Implemented status code.

另一个例子:

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

很可能会在数据库中使用相关颜色创建一个新的雪佛兰马里布.我说可能是因为 REST api 不需要与数据库结构直接相关.它只是一个屏蔽接口，以便保护真实数据(将其视为数据库结构的访问器和修改器).

is likely going to create a new chevy malibu in the db with the associated colors. I say likely as the REST api does not need to be directly related to the database structure. It is just a masking interface so that the true data is protected (think of it like accessors and mutators for a database structure).

现在我们需要讨论幂等性的问题.通常 REST 通过 HTTP 实现 CRUD.HTTP 使用 GET、PUT、POST 和 DELETE 来处理请求.

Now we need to move onto the issue of idempotence. Usually REST implements CRUD over HTTP. HTTP uses GET, PUT, POST and DELETE for the requests.

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

A very simplistic implementation of REST could use the following CRUD mapping:

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

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

There is an issue with this implementation: Post is defined as a non-idempotent method. This means that subsequent calls of the same Post method will result in different server states. Get, Put, and Delete, are idempotent; which means that calling them multiple times should result in an identical server state.

这意味着一个请求，例如:

This means that a request such as:

Delete: /cars/oldest

实际上可以实现为:

Post: /cars/oldest?action=delete

然而

Delete: /cars/id/123456

调用一次或调用 1000 次都会导致相同的服务器状态.

will result in the same server state if you call it once, or if you call it 1000 times.

处理删除 oldest 项目的更好方法是请求:

A better way of handling the removal of the oldest item would be to request:

Get: /cars/oldest

并使用结果数据中的ID发出delete请求:

and use the ID from the resulting data to make a delete request:

Delete: /cars/id/[oldest id]

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

An issue with this method would be if another /cars item was added between when /oldest was requested and when the delete was issued.

这篇关于REST API - 为什么使用 PUT DELETE POST GET?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！