PHP RESTful 应用程序的正确标头？

Question

目标： RESTful API
问题：我所拥有的方法是否低于真正的 RESTful API，还是缺少我被告知的内容？
这是一个 3 部分的问题..

假设我有一个 PHP 项目，它的 API 以 XML 或 JSON 格式返回数据，您可以像下面这样访问 API...

server.com/article/123 | Returns ID 123 using GET
server.com/article/new | Creates a new article using POST
server.com/article/123/edit | Edits an article with the ID 123 using POST
server.com/article/123/delete | Deletes article with ID 123 using POST

1)
我还经常读到PUT 应该用于编辑对象，下面我输入了POST 这个词，因为用户会发送一个POST 到tht URI 进行删除操作，我应该在php 中使用PUT 吗？改用这样的东西？

$_PUT  = array();  
if($_SERVER['REQUEST_METHOD'] == 'PUT') {  
    parse_str(file_get_contents('php://input'), $_PUT);  
}

2)
不久前我在 SO 上写的一个问题中告诉我，这类似于 RESTful API，但事实并非如此，我得到的答案是……

In short, your service is not RESTful, but it is close. Rather than specify actions (edit, delete, ...) in URL segments, you will want to make use of HTTP verbs (GET, PUT, POST, DELETE).

在阅读了无数关于该主题的文章并与我能找到的每个 API 进行比较之后，要么这个人不知道他在说什么，要么我只是不明白，我上面的示例如何不是 RESTful？

我想制作一个 RESTful API，如果需要，请帮我更正上面的示例？

3)
还假设我计划用类似这样的方式向用户返回 JSON 响应......

<?php
header('HTTP/1.1 200 OK');  
header('Content-type: application/json');

$data = // my code that returns the appropriate data;

echo json_encode($data);
?>

这是将结果返回给用户的正确方法还是我遗漏了什么？ 许多文章和问题都在讨论这个概念，但不像我的示例那样进入实际代码。

Answer 1

为了解决您问题的第 2 部分，更 RESTful 的 URL 和方法结构如下：

• server.com/articles/123 – GET：返回文章
• server.com/articles/123 – PUT：将文章替换为请求正文中的文章
• server.com/articles/123 – DELETE：删除文章
• server.com/articles/ – POST：创建一篇新文章

这里的想法是，URL 代表资源本身（在本例中为文章），而动词在可行的情况下表示您想对它做什么。在 true RESTful API 中，我能想到的最好的例子是最新版本的 GitHub API：据我所知，它们使用 HTTP 方法、响应代码和自定义 MIME 类型适当的。

在回答您问题的第 3 部分时，这当然是一种有效的方法，但如果您要使用自定义 MIME 类型，例如 application/vnd.myawesomesite.article+json，这将更容易在客户端进行解释，因为客户端可以使用 MIME 类型来确定如何解析结果：例如，客户端可以根据提供的 MIME 类型分派到不同的反序列化器和类。同样，GitHub 的人们在 their API docs 中给出了一些示例。

Answer 2

1. 您应该能够在 PUT 请求中使用$_POST，只要该请求包含正确的 Content-Type 标头即可。它是一个通用的超全局变量，当发送了 HTTP 正文并使用了正确的 Content-Type 标头时，应该始终填充它。事实上，它甚至可能出现在损坏的 GET 请求中。
2. 您的 URL 可能更加 RESTful。例如，server.com/article/123 不仅可以容纳 GET，还可以容纳 POST（编辑）和 DELETE（删除）。如果您已经在使用不同的请求方法，则无需使用单独的 URL。
3. RESTful 主要描述了客户端和服务器之间的通信方式，而不是它是如何做到的。过去我没有看到 201 标头被大量使用——通常 200 OK 就足够了。当然，没有什么可以阻止您使用 201 代码。

#protip：将所有数据包装在结果对象中，例如{'success':true,'result':<the result>,'resulttype':'article'}。使用您的 API（如果您发布 API）的开发人员会发现这很有帮助。对您而言，这意味着您可以轻松地向响应中添加额外信息。

Very interesting article on FourSquare's REST API