【发布时间】：2014-10-19 11:10:55
【问题描述】：
我一直在尝试寻找一个教程或网站来解释设计 api 的最佳实践，而不仅仅是代表典型的 Create-Read-Update-Delete 中的资源。
假设我想以 RESTful 方式表示基类库中的典型 API（一些表示单例模式/工厂模式等），我可以找到有关简单 POST、PUT、GET、DELETE 的大部分教程和信息表示 Create、Read、Update 的方法是不够的。
是否有一套标准指南以 RESTful 方式“REST 化”更复杂的 API 和/或标准设计模式？
例如，我不清楚为文件实例提供 MOVE 和 COPY 操作的最佳方法，并且有很多（所以！）很多方法可以实现；
POST http://www.api.com/api/file/<fileidentifier>/COPYTO/<newfileidentifier>
或
POST http://www.api.com/api/file?directory=<dir>&filename=<filename>
BODY { operation: "copy", newDirectory: "<$newdir>", newFilename: "<$newfilename>"
等等等等
我应该遵守哪些设计准则？
【问题讨论】：
-
好吧，在您的情况下，文件似乎是一种资源。该文件具有一些属性：名称和位置。当你“移动”你的资源时，你正在更新它的位置，所以我会在那个资源上使用一个 PUT（由“fileidentifier”标识）并在请求正文中传递新的位置。
-
也许不是最好的例子，因为我混合了移动和复制操作。我已经相应地编辑了问题。
-
复制资源是在现有资源的基础上创建新资源。所以我会使用 POST /files?source=/files/
（请注意，我对文件资源使用了复数形式。根据您的上下文，似乎是一个集合） -
感谢大卫 - 完全同意复数的使用。示例的选择可能会妨碍这里的问题，但现在让我们坚持下去。当然，在复制示例中，可以让客户端负责执行“获取”，然后使用 POST RESTful 查询创建新实例。但是，如果打算使用服务器端功能来完成此操作（即，为什么要将大文件下载到客户端，只是为了再次上传），您将如何构建 API？
-
嗯？如果您复制现有资源，您的资源已经在服务器端，不是吗？因此，与您的 POST 关联的功能正在服务器端执行所有操作。它只是触发复制，为其创建一个新标识符并将其作为复制操作的结果返回。