PUT与POST的文件上传的RESTful API来使用Zend Framework构建 [英] PUT vs. POST for files upload RESTful api to be built using Zend Framework

问题描述

我建立通过Ze​​nd_Rest_Route使用Zend Framework一个RESTful API。对于文件上传，我应该使用PUT或POST来处理这个过程？我试图尽可能使用REST动词的定义是一致的。请参考： PUT或POST：该故事的其余部分 的

我明白这个问题的方法是，我应该使用如果换上且仅当我更新指定资源的全部内容。我得知道确切的URL派上。在另一方面，我如果我发送一个命令到服务器创建指定资源的下属，使用一些服务器端算法使用POST。

让我们假设这是图像上传一个REST API。这是否意味着，如果服务器来处理图像文件（即创建缩略图，调整大小等），我应该使用POST;和使用PUT，如果我只是图像的原始文件只是保存到服务器？

如果我用PUT来处理文件上传，如果过程如下：

1. 用户发送GET请求来检索特定的URL文件被治。


2. 然后用户发送PUT请求从GET响应的URL。正在上传的文件是原始正是因为用户上传的。

我是很新的这个东西;所以希望我在这里决策意识...

如果您知道最好的方式做到这一点，随意评论为好。

解决方案

似乎有相当多的误解在这里。 PUT与POST未的真正的有关替代与创建，而是约幂等和资源命名。<​​/ P>

PUT是幂等操作。有了它，你给一个资源的名称并把作为资源的内容（可能与服务器生成的加法）的实体。最重要的是，在连续做了两次手术应该导致同样的事情，如果它做只是一次或做20次，对于同一件事一些相当松散的定义（它没有进行字节用户资格字节是相同的，但在信息提供的用户应完好无损）。你不会永远希望PUT导致被引发的金融交易。

POST是一个非幂等操作。你并不需要给资源，你正在寻找已创建的域名（也没有一个POST的有无的创建;如果它希望它可以删除重复的资源）。 POST通常用于执行创建资源与新崛起的名称，并告诉我的名字是什么 - 以新崛起名暗示缺乏幂等与适合。在其中创建新的资源，发回在Location头资源定位器完全是做正确的事。

现在，如果你正在服用的政策立场，即客户应的从不的创建资源名称，然后得到邮递创造完美契合（虽然理论上它可以根据所提供的实体做任何事情）和PUT是怎么做更新。为了使一个很大的意义，但不是所有的多RESTful应用程序;如果模型被presented给用户是一个文件系统中，具有用户提供的资源名使巨大量感和PUT成为主要的创建操作（和POST变得委派给不太常见的事像制作空目录等; WebDAV的甚至进一步降低了自检的需要）

摘要：不要以为在创建/更新方面，而是在谁使资源名称和操作是幂等条款。 PUT是​​真正创造-或更新，和POST是真的，什么 - 这，不应该成为的重复的，不管三七二十一。

I'm building a RESTful api using Zend Framework via the Zend_Rest_Route. For files upload, 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 PUT to. 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 images upload. Does that mean I should use POST if server is to manipulate the image files (i.e. create thumbnail, resize, etc); and use PUT if I just simply save the image raw file to the server?

If I use PUT to handle file upload, should the process be as follow:

1. User send a GET request to retrieve the specific URL for file to be PUT to.
2. Then the user send PUT request to the URL from the GET response. The file being uploaded is raw exactly as 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的文件上传的RESTful API来使用Zend Framework构建的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！