Question

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

POST /categories

要创建一个类别：

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

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

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

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

或者应该有一个

POST /bulk

允许他们一次做任何操作（创建，阅读，更新和删除）？

Answer 1

在真正的REST中，您可能应该在多个单独的调用中对此进行POST。原因是每一个都会产生新的表示。你怎么能期望得到这个呢？

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

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

但是，如果您需要批量，则创建批量。尽可能保持教条，但如果没有，实用主义就能完成工作。如果你太依赖于教条主义，那么你永远不会做任何事情。

Here is a similar question

Here is one that suggests HTTP Pipelining to make this more efficient

Answer 2

没有什么特别的错误，你有一个批量操作，你POST，激活（它将是非幂等的，所以POST是正确的动词），但有一些警告：

您正在制作多个资源，因此您需要使用多个网址进行回复。这意味着您无法使用重定向模式：您必须以某种形式发回URL列表。
您遇到的问题是批量操作通常不易被发现。可发现性是RESTfulness最重要的事情之一，因为它意味着有人可以在没有服务器作者的大量帮助的情况下找到如何编写客户端。
当您进行批量操作时处理部分失败仍然存在问题。这也是任何其他范例的问题（我看到人们在使用SOAP的扩展时将其自身束缚在一起）所以这并不奇怪，但除非你能保证所有的创作将起作用，你将不得不弄清楚当你创造一个资源而不能创造第二个资源时会发生什么。（另外，如果批量请求需要完成第三个请求，您会继续尝试吗？）

最简单的方法是每个请求支持一个创建;这是一个更容易理解的模式，可以更好地理解。

Answer 3

使用POST一次创建多个资源没有任何问题（只是不要尝试使用PUT）。它不是“非RESTful”，特别是如果您为批量操作本身创建一个表示。我建议您在创建单个资源的同时创建索引资源，并返回“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."}]

Answer 4

在你的情况下，我也会采用/ 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 ->

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

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

Answer 5

实际上，直到今天，这仍然是一个热门话题，但是简单地说，我几乎总是说，每种练习总是有一个适合连击的场景。例如： 1.如果您从帖子中收到喜欢的消息，则不需要大量，因为每个评论只有一个喜欢的消息。 2.如果您收到最喜欢的评论，则可以考虑考虑某人查看他阅读的评论，然后选中所有他的收藏并发送一次，来容纳大部分评论。

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

使用restful HTTP创建单个和多个资源

5 个答案: