根据HTTP/1.1规范:
该
POST方法用来请求原始服务器接受被附在请求由标识的资源的新下属实体Request-URI的Request-Line
换句话说,POST用于创建.
该
PUT方法请求将所包含的实体存储在提供的实体下Request-URI.如果Request-URI引用已经存在的资源,则封闭的实体应该被视为驻留在源服务器上的实体的修改版本.如果Request-URI未指向现有资源,并且该URI能够被请求用户代理定义为新资源,则源服务器可以使用该URI创建资源.
也就是说,PUT用于创建或更新.
那么,应该使用哪一个来创建资源？或者需要支持两者？
我有REST API,它暴露了一个复杂的大型资源,我希望能够克隆这个资源.假设资源暴露在/resources/{resoureId}
要克隆资源10我可以做类似的事情.
GET /resources/10 POST /resources/put的主体包含GET /resources/10没有id 的表示的副本,以便POST创建新的资源.这种方法的问题是资源非常庞大和复杂,将完整的表示返回给客户端然后让客户端将其发送回来实际上是没有意义的,因为这只会浪费带宽,而cpu就是服务器.克隆服务器上的资源要容易得多,所以我想这样做.
我可以做类似的事情POST /resources/10/clone,POST resources/clone/10但这两种方法都错了,因为URL中的动词.
构建可以在这种情况下使用的url的最"安静/名词"方式是什么？
某些文件系统的基本操作(例如ls和rm)有明显的对应关系,但是如何实现不直接的RESTful操作,如cp或mv？
作为问题的答案如何在REST中实现资源的复制粘贴？建议,首选的实现cp方式包括获取资源,删除它并使用新名称再次将其恢复.
但如果我需要有效地做呢？例如,如果资源的规模很大？如何消除资源有效负载到客户端和返回原始服务器的多余传输？
这是一个例子.我有一个资源:
/videos/my_videos/2-gigabyte-video.avi
我想将它复制到一个新资源:
/videos/johns_videos/copied-2-gigabyte-video.avi
我如何以RESTful方式实现复制,移动或其他文件系统操作？还是有正确的方法？我做错了吗？
您将如何以RESTful方式实现复制粘贴支持？
假设我有书店资源.每家商店都有书籍
http://mydomain.com/rest/book-stores/1
http://mydomain.com/rest/book-stores/1/books/12
我需要客户端能够调用书籍的复制粘贴到另一个商店.
实施以下内容:
PUT http://mydomain.com/rest/books/1/copy-paste
看起来很像RPC.您是否有任何建议如何以RESTful方式对此操作进行建模？