上传文件的 PUT 与 POST - 使用 Zend 框架构建的 RESTful API [英] PUT vs. POST for Uploading Files - RESTful API to be Built Using Zend Framework
问题描述
我正在通过 Zend_Rest_Route 使用 Zend Framework 构建 RESTful API.对于上传文件，我应该使用 PUT 还是 POST 来处理该过程?我试图尽可能与 REST 动词的定义保持一致.请参考:PUT 或 POST:故事的其余部分.
我的理解是，当且仅当我更新指定资源的全部内容时，我才应该使用 PUT.我必须知道使用 PUT 的确切 URL.另一方面，如果我向服务器发送命令以使用某些服务器端算法创建指定资源的下级，我应该使用 POST.
假设这是一个用于上传图像的 REST API.这是否意味着如果服务器要操作图像文件(即创建缩略图、调整大小等)，我应该使用 POST；如果我只想将原始图像文件保存到服务器，请使用 PUT?
如果我用PUT来处理文件上传，应该是这样的:
- 用户发送 GET 请求以检索特定 URL 以通过 PUT 上传文件.
- 然后用户向该 URL 发送 PUT 请求.
上传的文件是原始文件 - 正是用户上传的文件.
我对这个东西很陌生；所以希望我在这里有意义...
如果你知道最好的"如何做到这一点，请随时发表评论.
这里似乎有不少误解.PUT 与 POST 不是真正关于替换与创建，而是关于幂等性和资源命名.</p>
PUT 是幂等操作.使用它，您可以指定资源的名称和要作为该资源内容放置的实体(可能带有服务器生成的附加内容).至关重要的是，连续执行两次操作应该会产生与只执行一次或执行 20 次相同的结果，对于同一件事"的一些相当松散的定义(它不必是字节换-字节相同，但用户提供的信息应该是完整的).您永远不会希望 PUT 导致触发金融交易.
POST 是非幂等操作.您不需要提供您要创建的资源的名称(POST have 也不需要创建；如果它愿意，它可以对资源进行重复数据删除).POST 通常用于实现使用新命名的名称创建资源并告诉我名称是什么"——新命名的名称"所隐含的幂等性的缺乏与此相符.在创建新资源时，在 Location 标头中发回资源的定位符是完全正确的做法.
现在，如果您采取客户应该从不创建资源名称的政策立场，那么您就会发现 POST 非常适合创建(尽管理论上它可以根据提供的实体执行任何操作)和 PUT 是如何进行更新.对于许多有意义的 RESTful 应用程序，但不是全部；如果呈现给用户的模型是一个文件系统，那么让用户提供资源名称就很有意义，并且 PUT 成为主要的创建操作(并且 POST 被委托给不太常见的事情，比如创建一个空目录等等上；WebDAV 进一步减少了 POST 的需要).
总结:不要从创建/更新的角度考虑，而要考虑谁为资源命名以及哪些操作是幂等的.PUT 是真正的创建或更新，而 POST 是真正做任何不应该重复的事情.
I'm building a RESTful API using Zend Framework via the Zend_Rest_Route. For uploading of files, should I use PUT or POST to handle the process? I'm trying to be as consistent as possible with the definition of the REST verbs. Please refer to: PUT or POST: The REST of the Story.
The way I understand this is that I should use PUT if and only if I'm updating the full content of the specified resource. I'll have to know the exact URL to use PUT. On the other hand, I should use POST if I'm sending a command to the server to create a subordinate of the specified resource, using some server-side algorithm.
Let's assume this is a REST API for uploading images. Does that mean I should use POST if the server is to manipulate the image file (i.e. create thumbnail, resize, etc); and use PUT if I just want to save the raw image file to the server?
If I use PUT to handle a file upload, should the process be as follows:
- The user sends a GET request to retrieve the specific URL to upload the file by PUT.
- Then the user sends a PUT request to that URL.
The file being uploaded is raw - exactly the one the user uploaded.
I'm quite new to this stuff; so hopefully I'm making sense here...
If you know the "best" way to do this, feel free to comment as well.
There seems to be quite a bit of misunderstanding here. PUT versus POST is not really about replace versus create, but rather about idempotency and resource naming.
PUT is an idempotent operation. With it, you give the name of a resource and an entity to place as that resource's content (possibly with server-generated additions). Crucially, doing the operation twice in a row should result in the same thing as if it was done just once or done 20 times, for some fairly loose definition of "the same thing" (it doesn't have to be byte-for-byte identical, but the information that the user supplied should be intact). You wouldn't ever want a PUT to cause a financial transaction to be triggered.
POST is a non-idempotent operation. You don't need to give the name of the resource which you're looking to have created (nor does a POST have to create; it could de-duplicate resources if it wished). POST is often used to implement "create a resource with a newly-minted name and tell me what the name is" — the lack of idempotency implied by "newly-minted name" fits with that. Where a new resource is created, sending back the locator for the resource in a Location header is entirely the right thing to do.
Now, if you are taking the policy position that clients should never create resource names, you then get POST being the perfect fit for creation (though theoretically it could do anything based on the supplied entity) and PUT being how to do update. For many RESTful applications that makes a lot of sense, but not all; if the model being presented to the user was of a file system, having the user supply the resource name makes a huge amount of sense and PUT becomes the main creation operation (and POST becomes delegated to less common things like making an empty directory and so on; WebDAV reduces the need for POST even further).
The summary: Don't think in terms of create/update, but rather in terms of who makes the resource names and which operations are idempotent. PUT is really create-or-update, and POST is really do-anything-which-shouldnt-be-repeated-willy-nilly.
这篇关于上传文件的 PUT 与 POST - 使用 Zend 框架构建的 RESTful API的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
