30

在我的 API 服务器中，我定义了这条路线：

POST /categories

要创建一个类别，您可以：

POST /categories {"name": "Books"}

我认为如果你想创建多个类别，那么你可以这样做：

POST /categories [{"name": "Books"}, {"name": "Games"}]

我只是想确认这是 Restful HTTP API 的一个好习惯。

或者应该有一个

POST /bulk

允许他们一次执行任何操作（创建、读取、更新和删除）？

4

5 回答 5

32

在真正的 REST 中，您可能应该在多个单独的调用中发布它。原因是每一个都会产生一个新的表示。否则，您将如何期望得到回报。

每个帖子都应返回结果资源位置：

POST -> New Resource Location
POST -> New Resource Location
...

但是，如果您需要批量，则创建一个批量。尽可能教条，但如果不是，实用主义就能完成工作。如果你太执着于教条主义，那么你永远做不到任何事情。

这是一个类似的问题

这是一个建议使用 HTTP Pipelining 来提高效率的方法

于 2012-06-20T14:45:47.420 回答
17

将批量操作发布到激活并没有什么特别的问题（它将是非幂等的，因此 POST 是正确的动词），但有一些警告：

  • 您正在制作多个资源，因此您需要使用多个 URL 进行响应。这意味着您不能使用重定向模式：您必须以某种形式发回 URL 列表。

  • 您的问题在于批量操作通常不太容易被发现。可发现性是关于 RESTfulness 最重要的事情之一，因为这意味着有人可以在没有服务器作者大量帮助的情况下找出如何编写客户端。

  • 在进行批量操作时处理部分故障仍然存在问题。这也是任何其他范式的问题（我看到人们在使用 SOAP 扩展时为此束手无策），所以这并不奇怪，但除非你能保证所有的创作都能正常工作，否则你就是必须弄清楚当您制作一种资源而未能制作第二种资源时会发生什么。（另外，如果批量请求想要完成第三个请求，你会继续尝试吗？）

最简单的方法是支持每个请求创建一个；这是一个更容易正确的模式，并且更容易全面理解。

于 2012-06-20T14:57:36.987 回答
4

使用 POST 一次创建多个资源没有任何问题（只是不要使用 PUT 尝试）。它不是“非 REST-ful”，尤其是当您为批量操作本身创建表示时。我建议您在创建单个资源的同时创建一个索引资源，并返回一个“303 See Other”给它。然后，该索引表示将包含指向所有已创建资源的链接（如果其中任何一个资源失败，还可能包含错误信息）。

POST /categories/uploads/
[{"name": "Books"}, {"name": "Games"}]

    303 See Other
    Location: /categories/uploads/321/

（其实现在想想，201可能比303好）

GET /categories/uploads/321/

    200 OK
    Content-Type: application/json

    [{"name": "Books", "link": "/categories/Books/"},
     {"name": "Games", "error": "The 'Games' category already exists."}]
于 2012-06-20T17:03:43.130 回答
3

在您的情况下，我也会采用 /bulk 资源方式。但我建议的模式如下，据我所知，这是最自然的：使用 202 Accepted 状态代码。

批量请求的想法是服务器不应该被迫立即回答，因为这意味着客户端需要等到它的批量请求完成。

这是模式：

POST /bulk [{"name": "Books"}, {"name": "Games"}]
202 Accepted | Location: /bulk/processing/status/resourceId

GET /bulk/processing/status/resourceId
entry = "REST in peace" | completed | 0 errors | /categories/category/resourceId
entry = "Walking dead" | processing | 0 errors ->

因此，客户端将批量信息发布到服务器。服务器仅使用 202 接受它们，这不能保证响应时的处理状态。但是服务器也提供了一个状态资源的链接。在这里，客户端可以查看每个创建的资源和处理状态。完成后，客户端可以通过给定的链接访问资源。错误情况可以由客户端识别，错误数据可能会通过 PUT 在已完成资源上重新发送。

最后，我通常遵循的一个好建议是：每当您在设计中遇到无法映射到 HTTP 功能的资源时，可能是因为缺少资源。

于 2013-09-29T07:37:32.793 回答
2

实际上，直到今天这仍然是一个热门话题，但简化一些事情，我几乎经常说每次练习都有一个适合击球手的场景。例如： 1. 如果您从帖子中收到喜欢，则不需要批量，因为以防每条评论只有一个喜欢。2. 如果您收到最喜欢的评论，考虑某人查看他阅读的评论并选中他所有的收藏并发送一次，可以很好地适应批量。

同样，这是基于我使用 Restful API 的经验，但目前为了多任务处理和其他事情，我和我的同事发现我们自己在我们所做的大多数 MIS（管理信息系统）中一直在做大部分工作。这是因为现代网络应用程序和移动应用程序可以做很多工作并将最终结果发送到后端，这样后端只要接收到的数据不违反商业逻辑。

于 2019-11-05T13:59:55.760 回答