我一直在研究/创建一个REST api，在backbone.js到php上下文。
我理解HTTP动词的概念以及何时应该使用它们
GET - select
POST - create
PUT - update
DELETE - delete
我也理解将标识符作为语义URL传递的概念，例如
GET http://api/users/123
DELETE http://api/users/123
在这些情况下，“123”是业务逻辑用于获取/删除用户的ID。
但POST和PUT上下文怎么样？发送请求时
PUT http://api/users/123
api将使用提供的参数更新用户ID 123，这是我的问题出现的地方。
我会假设要更新的输入参数将作为PUT参数发送。在php语法中，这表示为：file_get_contents('php://input')（这与删除请求相同。）
通过backbone.js测试时，它可以很好地工作。
但是当我尝试用
创建一个新元素时 POST http://api/users/
我会假设输入值将作为POST参数/在php语法中发送，这表示为$_POST。但这不起作用。
经过一些测试，并阅读rails风格的REST apis（这是骨干文档建议的），我意识到所有请求变量以相同的方式发送。如果我更改我的代码以使用file_get_contents('php://input')来获取每个请求类型的请求参数，那么骨干网就可以正常工作。
这是REST apis的标准公平吗？或者只是“铁路味”的？
答案 0 :(得分：1)
PUT，POST，PATCH等（除了GET和DELETE *之外的所有内容）都接受请求主体。通常，数据传递为：
URL编码的名称/值对的字符串（与URL查询字符串完全相同），由服务器解码并解析为$_POST（或类似，取决于您选择的Web框架）。 这通常依赖于Content-Type标头设置为application/x-www-form-urlencoded （浏览器在提交表单时默认执行此操作）。如果您在file_get_contents('php://input')但未$_POST中看到数据，则此标头很可能不存在或设置为其他值。如果您使用的是Chrome，则可以在开发工具的“网络”标签中查看客户端发送的标题和正文。
另一种流行的请求体格式是使用Content-Type: application/json，然后将JSON字符串写入正文。这可以通过file_get_contents('php://input')访问，然后使用JSON解析器进行解析。
*关于DELETE的注意事项：it's a little unclear whether or not using a request body with DELETE is allowed or a good practice。