PUT与POSTfile upload使用Zend Framework构buildREST风格的api
我正在通过Zend_Rest_Route使用Zend Framework构build一个RESTful API。 对于file upload，我应该使用PUT还是POST来处理这个过程？ 我试图尽可能与REST动词的定义保持一致。 请参考： PUT或POST：故事的REST
我理解这一点的方式是，当且仅当我更新指定资源的完整内容时，我应该使用PUT。 我将不得不知道要input的确切URL。 另一方面，我应该使用POST，如果我发送一个命令到服务器创build一个指定资源的下属，使用一些服务器端algorithm。
假设这是一个用于图片上传的REST API。 这是否意味着我应该使用POST如果服务器是操纵图像文件（即创build缩略图，resize等）; 并使用PUT，如果我只是简单地将图像原始文件保存到服务器？
如果我使用PUT来处理file upload，那么过程如下：
- 用户发送GET请求来检索要放置到的文件的特定URL。
- 然后用户从GET响应发送PUT请求到URL。 正在上传的文件与用户上传完全一样。
我对这个东西相当陌生， 所以希望我在这里有道理…
如果你知道这个“最好”的方法，请随时发表评论。
这里似乎有不less误解。 PUT与POST不是真正的替代与创造，而是关于幂等性和资源命名。
PUT是一个幂等操作。 有了它，你可以给资源和实体的名称作为资源的内容（可能是由服务器生成的添加）。 至关重要的是，连续执行两次操作应该会产生相同的结果，就好像它只执行了一次或完成了20次一样，对于“相同的事情”的一些相当松散的定义（它不一定是字节换的，字节相同，但是用户提供的信息应该是完整的）。 你永远不会想要一个PUT来引发一个财务交易。
POST是一个非幂等操作。 您不需要提供您正在创build的资源的名称（也不需要创buildPOST;它可以根据需要去重复资源）。 POST经常被用来实现“用新创build的名字创build一个资源，并告诉我名字是什么” – “新铸造的名字”所暗含的缺乏幂等性就符合这一点。 在创build新资源的情况下，发回位置标题中资源的定位符完全是正确的。
现在，如果你采取的政策立场，客户不应该创build资源名称，那么你就可以让POST成为完美的创造（尽pipe理论上它可以根据提供的实体做任何事情），PUT是如何更新的。 对于很多有意义的RESTful应用程序，但不是全部; 如果向用户呈现的模型是文件系统，那么让用户提供资源名称会产生很大的意义，而PUT将成为主要的创build操作（POST将被委派给不太常见的东西，比如创build一个空目录等等on; WebDAV进一步降低了对POST的需求）。
总结：不要以创build/更新的方式来思考，而应该根据谁来创build资源名称以及哪些操作是幂等的。 PUT实际上是创build或者更新的，而POST是真正的任何事情，它们都应该被重复 – 无所不能。
对于file upload，除非它正在replace现有的资源，绝对使用POST。
在REST中，POST是创build新资源，PUTreplace现有资源，GET检索资源，DELETE删除资源。
来源： http : //en.wikipedia.org/wiki/Representational_state_transfer#RESTful_web_services
REST不是一个标准，所以这很容易变成一场宗教战斗。 被认为是“RESTful”的AtomPub和OData标准确实同意这个：POST =创build，而PUT =更新
简单的答案是您应该使用PUT而不是POST，因为您将replace文件的全部内容。 看看PUT vs POST
我将不得不知道要input的确切URL
不。您不必知道PUT的URL，即在PUT操作之前，PUT URI不必存在。 如果资源不存在，则创build资源。 如果资源已经存在，那么资源将被replace为新的表示。
引用链接的文章：
PUT将页面放在特定的URL上。 如果在那里已经有一个页面，它被replace成全部。 如果那里没有页面，则创build一个新页面。 这意味着它就像一个DELETE，然后插入一个具有相同主键的新logging
