8

以 RESTful 的方式思考，使用 POST 在一次调用中创建资源及其子资源是否正确？在我的应用程序中，我有资源/notices/{notice}和子资源/notices/{notice}/photos/{photo}。A{photo}不能没有 a 存在{notice}，但 a{notice}不一定有照片。通常，我必须先做一个 POST 来创建通知，然后再做一个 POST 来添加照片。

现在我想允许创建一个直接附有照片的通知，允许创建一个对 /notices/{notice}/photos/{photo}/notices/{notice}的/notices/{notice}/photos/{photo}单个 POST 请求，其中包含描述两个资源的多部分内容（JSON通知，照片的二进制文件）。我想我只会为子资源返回 Location 标头。

本质上，我希望这可以防止 Android 客户端向服务器发送两个 POST 请求以上传带有照片的通知。这个对吗？还是违反了 REST 原则？我应该考虑将它们分开并提出两个不同的请求吗？还是将照片视为与通知不同的实体是错误的？我应该只保留/notices/{notice}作为资源，使用 PUT 添加照片吗？

哪个是最好的解决方案？

4

2 回答 2

4

是的，在创建父资源的同时创建子资源并没有错。甚至可以使用PUT而不是POST这样做，因为父 URL 下的所有内容都是您正在上传的资源的一部分/属于您正在上传的资源。

编辑：

现在我想允许创建一个直接附有照片的通知，允许/notices/{notice}创建/notices/{notice}/photos/{photo}一个POST请求/notices/{notice}/photos/{photo}

这个我不同意。我建议发布到集合资源的 URL /notices，. 您将通知及其照片作为单一表示（请求正文）提供。然后，后端将为通知和任何组成照片创建资源。

于 2013-01-11T11:37:28.680 回答
1

尽管在许多情况下它是必不可少的，但 RESTful 架构风格并未正式解决多次编辑/创建问题。

当您需要报告部分集合的故障时，问题就开始了，当故障有不同的原因时，问题会变得更糟。

它将影响选择正确的超媒体控件，这对于客户在给定的事务/对话中找到前进的方式至关重要。

所以我的建议是有一个嵌套循环或 POST 请求，而不是一个 POST 来创建嵌套 Resources ，以便更容易和更清楚地解决每个 Resource 状态更改。

于 2013-01-11T11:44:08.113 回答