RESTful设计似乎提倡平面或浅层结构化表示(至少在资源表示为XML时).资源表示应该只包含URI标识的资源.我想知道何时在父资源中提供资源的子资源是明智的吗？
详细说明一下,请考虑一下:公司可能有多名员工.通常情况下,这种情况可能被设计为两个独立的资源,即公司和员工,员工将成为公司的子资源.
/company/acme/
/company/acme/employees/
/company/acme/employee/john
使用此URI设计,公司表示应包含指向其员工的链接,但XML表示可能不包括emplyoyees本身.
因此,何时通过父母提出子项？是否存在仅通过其父项呈现子项目是明智的情况.我的意思是根本没有子项的URI.只能通过父资源访问它们.
<company>
<name>Acme</name>
<employees>
<employee>John</employee>
<employee>Jack</employee>
</employees>
</company>
仅提供一种访问资源的方法是明智的:如果父项公开其子项,那么子项也可以有明确的URI吗？因此,如果公司的XML包含公司的员工,那么提供/ company/acme/employees URI dispite是否有意义,您可以通过公司资源获得相同的信息？
某些文件系统的基本操作(例如ls和rm)有明显的对应关系,但是如何实现不直接的RESTful操作,如cp或mv？
作为问题的答案如何在REST中实现资源的复制粘贴？建议,首选的实现cp方式包括获取资源,删除它并使用新名称再次将其恢复.
但如果我需要有效地做呢？例如,如果资源的规模很大？如何消除资源有效负载到客户端和返回原始服务器的多余传输？
这是一个例子.我有一个资源:
/videos/my_videos/2-gigabyte-video.avi
我想将它复制到一个新资源:
/videos/johns_videos/copied-2-gigabyte-video.avi
我如何以RESTful方式实现复制,移动或其他文件系统操作？还是有正确的方法？我做错了吗？