RESTful复制/移动操作？

我试图设计一个类似RESTful文件系统的服务,复制/移动操作给我带来了一些麻烦.

首先,使用PUT到文件的最终URL上传新文件:

PUT /folders/42/contents/

问题是,如果新文件已经在不同的URL下驻留在系统上怎么办？

复制/移动创意1:使用自定义标题进行PUT.

这类似于S3的副本.PUT看起来与上传相同,但带有自定义标题:

PUT /folders/42/contents/
X-custom-source: /files/5

这很好,因为在复制/移动时很容易更改文件的名称.但是,S3不提供移动操作,可能是因为使用此方案的移动不是幂等的.

复制/移动Idea 2:POST到父文件夹.

这类似于Google Docs副本.POST目标文件夹,其中包含描述源文件的XML内容:

POST /folders/42/contents
...
/files/5
foo

我可能能够POST到文件的新URL来更改其名称..？否则,我不得不在XML内容中指定一个新名称,这会放大这个想法的RPCness.它也与想法1的上传操作不一致.

最终我正在寻找易于使用和理解的东西,所以除了对上述内容的批评之外,新的想法当然是受欢迎的!

要创建通常使用的新资源POST.这应该在服务器创建的URI上创建新资源.

POST /folders/42/contents/fileName
newFile

REST所说的是POST新资源位于服务器确定的路径中.这就是复制甚至在(windows)文件系统中的工作方式.考虑将文件复制到已存在的名称,然后上述示例的响应可能是:

/folders/42/contents/newFile-2

然后通过第一次复制然后删除进行移动.您不应该在一个请求中执行这两个操作.

编辑:
我发现书籍RESTful Web Services Cookbook非常好.

第11章处理Copy方法并在11.1中推荐以下内容:

问题 您想知道如何制作现有资源的副本.

解决方案 设计可以创建副本的控制器资源.客户端向此控制器发出POST请求以复制资源.要使POST成为条件,请向客户端提供一次性URI.控制器创建副本后,返回响应代码201(已创建),其中包含副本的URI的Location标头.

请求发布 /专辑/ 2009/08/1011 /复制; t = a5d0e32ddff373df1b3351e53fc6ffb1

响应

urn:example:album:1014

...

HTTP规范说如果资源已经存在，则更新资源并返回200。如果资源不存在，则创建它，然后返回201。

编辑：
好的，我读错了。我更喜欢POST而不是父文件夹方法。您也可以使用查询字符串参数引用源文件。例如

POST /destination/folder?sourceFile=/source/folder/filename.txt