14

我有一个自己构建的 RESTFul 服务器 API。它的某些部分没有控制资源，我无法将相关的 URL + HTTP 方法映射到服务器上执行的操作。

例如，我可以使用 备份服务器上的每个资源POST /backup，但我不确定这是否是最合适的映射。单一资源呢？POST /backup/id我应该使用：还是通过将 id 声明为我发送的变量来指定它：POST /backup <id>

请给我一些关于如何最恰当地构建它的提示，以便我的 API 易于掌握。

4

4 回答 4

7

这取决于您是否在每次调用时都在数据库上创建一个新的备份对象，或者您是否有许多仅保存最后一个值的备份对象（例如，不同文件的备份）。

POST /backups用于创建新对象，因此如果您始终创建新备份，则正确答案。

PUT /backups/id如果您要更新同一对象中的备份数据。

恢复路线

于 2013-05-23T15:24:03.223 回答
6

我相信POST /backup（备份所有资源）和POST /backup <id>（备份单个资源）在这里最适合您。

CRUD 映射：就像 Ray 所说，备份不能很好地映射到 CRUD；您希望服务器上的操作资源来执行该功能。Mark Massé 撰写了O'Reilly 的有关 REST API 设计的书，他的建议是在这种情况下使用服务器上的操作资源（请参阅关于操作原型的幻灯片 20）。

URI 设计：操作资源应该是 URI 的最后一段，没有子资源。当您看到下面哪种 HTTP 方法最适合此处的原因时，这将是有意义的。

HTTP 方法：备份不应该是幂等操作，因此您需要非幂等的 HTTP 方法。这POST.不仅是 PUT 幂等的，您指定的 URI 就是您放置要发送的资源的位置。如果你想安静，你不想这样做。POST 的部分目的及其非幂等性被指定为

向数据处理过程提供数据块，例如提交表单的结果

这就是你想要的。

REST： 作为一个分层系统，服务器（通过它的动作资源（备份方法））应该指定它的输出应该去哪里；客户不应该容纳这种逻辑。

因此，通过这种方式，您的备份操作资源可以自由确定要将备份放在哪里（可能是存储资源 ( /backups)；请参见幻灯片 19）以及是否要覆盖以前的备份或是否要实现某种形式的版本控制（REST 设计没有考虑到的东西）。所以基本上你是在正确的轨道上！

于 2013-05-23T18:44:31.263 回答
3

虽然 RESTafarians（REST 纯粹主义者）会说 REST API 中的唯一操作应该是映射 HTTP 动词的基本 CRUD 操作—— GET、、PUT和POST——DELETE这有时是不切实际的，并且会使你的工作比它需要的更困难是。如果您想要其他操作，例如备份，那么您可能需要考虑使用 HTTP 动词和嵌入在请求 URL 中的操作名称来确定正在执行的操作的 RPC 样式 REST 实现。

GET    /resource/select
GET    /resource/select?id={id}
PUT    /resource/update?id={id}
POST   /resource/insert
DELETE /resource/delete?id={id}
PUT*   /resource/backup?id={id}
GET    /resource/backup?id={id}

*如果您的应用程序维护资源的多个备份，并且您希望备份操作始终创建新备份，那么通常使用POST备份不是幂等的。如果您只维护一个备份并且备份操作只是更新资源的备份，那么您应该使用 PUT，因为在这种情况下备份是幂等的。

于 2013-05-23T15:45:45.777 回答
0

您可以使用id =123POST /backups?resource=car&id=123来备份汽车（当然，如果您愿意，可以在 URL 中传递 JSON 对象而不是参数）。还要注意backups中的复数，这是一个细节，但它更好地传达了一个或多个备份可以在此 URI 下找到的事实。

如果您想替换以前创建的备份，那么，正如其他人所提到的，您可以使用 PUT，也许像这样PUT /backups/456?resource=car&id=123，它表示“将 id=456 的备份替换为您将通过使用 id=123 备份汽车创建的备份”。

最后，如果您想一步备份所有资源，您可以使用类似POST /backups?all=true或类似的相关参数。如果您希望这些备份替换以前的备份，在运行此之前，您可以使用DELETE /backups.

于 2013-05-24T00:05:44.803 回答