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

Question

所以,我正在浏览一些关于创建REST API的文章.其中一些建议使用所有类型的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服务还不太了解(还).但是,通过常规或(包含方法名称和所有参数)接受JSON对象并不是更容易,然后也以JSON响应.我们可以通过PHP轻松地序列化/反序列化,并且可以使用该数据执行任何操作,而无需处理不同的HTTP请求方法.POSTGETjson_encode()json_decode()

我错过了什么吗？

更新1:

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

Answer 1

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

您建议使用post请求来访问JSON,这是访问/操作数据的完美有效方式.

REST是一种有意义的数据访问方法.当您在REST中看到请求时,它应立即显示数据发生的情况.

例如:

GET: /cars/make/chevrolet

可能会返回一系列雪佛兰汽车. 一个好的REST api甚至可能在查询字符串中包含一些输出选项,?output=json或者?output=html允许访问者决定应该编码信息的格式.

有点思考如何合理地整合数据类型为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 实现CRUD.HTTP使用GET,PUT,POST和DELETE为请求.

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

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

此实现存在问题:Post被定义为非幂等方法.这意味着后续调用相同的Post方法将导致不同的服务器状态.获取,放置和删除是幂等的; 这意味着多次调用它们会导致相同的服务器状态.

这意味着请求如下:

Delete: /cars/oldest

实际上可以实现为:

Post: /cars/oldest?action=delete

而

Delete: /cars/id/123456

如果你调用一次,或者你调用它1000次,将导致相同的服务器状态.

处理oldest物品移除的更好方法是请求:

Get: /cars/oldest

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

Delete: /cars/id/[oldest id]

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

Answer 2

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

安全的方法

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

幂等方法

只要有可能,您应该使用"幂等"方法,如GET,HEAD,PUT和DELETE,这些方法不会产生副作用,因此不易出错/易于控制.

资源

Answer 3

简而言之,REST强调动词的名词.随着API变得越来越复杂,您需要添加更多内容,而不是更多命令.

Answer 4

你问:

通过普通的$ _POST接受JSON对象,然后以JSON响应也不容易

来自维基百科的REST:

RESTful应用程序可以最大限度地利用所选网络协议提供的预先存在的,定义良好的界面和其他内置功能,并最大限度地减少在其上添加新的特定于应用程序的功能

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

不鼓励使用自定义数据协议(即使它们构建在标准数据协议之上,例如SOAP或JSON),并且应该最小化以最好地符合REST意识形态.

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

您正在使用的实际对象可以是任何格式.我们的想法是尽可能多地重用HTTP来公开用户想要对这些资源执行的操作(查询,状态管理/变异,删除).

你问:

我错过了什么吗？

有关REST和URI语法/ HTTP动词本身的更多信息.例如,一些动词是幂等的,而另一些则不是.我在你的问题中没有看到任何相关内容,所以我没有费心去尝试.其他答案和维基百科都有很多好的信息.

此外,如果您使用的是真正安静的API,那么您可以了解基于HTTP构建的各种网络技术,您可以充分利用这些技术.我从认证开始.

Answer 5

关于使用扩展来定义数据类型.我注意到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  

Answer 6

我错过了什么吗？

是的。;-)

这种现象的存在是由于均匀界面约束。REST 喜欢使用已经存在的标准，而不是重新发明轮子。HTTP 标准已经被证明具有高度可扩展性（Web 已经运行了一段时间）。为什么我们要修复没有损坏的东西？

注意：如果您想将客户端与服务解耦，统一接口约束非常重要。它类似于为类定义接口以将它们彼此解耦。办公室。这里的统一接口由HTTP、MIME 类型、URI、RDF、链接数据词汇、Hydra 词汇等标准组成。