RESTApi EndPoint获取多个资源

Question

下面的操作是检索所有的书籍，只检索那些进入请求的书。这显然是一个GET操作。

从你的角度来看，做这两件事有什么好处(正反)：

• 注：

GET -api/library/2/book/

检索库2中的所有书籍。

• 使用GET的：

获取-api/library/2/book/3/5/10/33/./pages

• 使用POST的：

POST -api/library/2/图书/页

Body:

{
    "books_id": [
        2,
        30,
        40,
        20,
        30
    ]
}

对于使用POST或GET方法来实现这一点，我真的很怀疑。如果有100到200本书要检索，URL上的图书Ids就会变得非常混乱。我想在这里得到一些启示。

我使用PHP来处理Rest应用程序，上面的所有方法都是有效的。

Answer 1

该操作符合到达方法的标准语义，因此符合各种软件的期望。例如：

• 许多HTTP客户端都知道，如果出现错误，他们可以自动重试GET请求
• 更容易缓存响应以获取

如果您的图书If独立于库If，那么最好删除对库的引用，只执行以下操作

GET /api/books/3,5,10,33/pages

如果有100-200本书需要检索，URL上的图书Ids会变得非常混乱。

如果每个图书ID都有6位长，这就等于700到1400字节。这完全在任何好的HTTP客户端所支持的范围内。要真正实现URL长度的实际限制，您需要更多的书籍--但您真的需要(或希望)支持一次检索这么多页面吗？

(或者，您的图书ID可能要长得多--也许是UUID。)

如果您确实遇到了URL长度的限制，可以使用POST到专用的“端点”：

POST /api/books/bulk-pages

{"books_id": [3, 5, 10, 33]}

POST在RFC 7231§4.3.3中被定义为一种“全部捕获”方法：

根据资源本身的特定语义处理包含在请求中的表示。例如，POST用于下列功能(除其他外)： O向数据处理过程提供数据块，例如输入到HTML表单中的字段；

令人好奇的是，最近有人尝试使用标准化搜索方法，允许像POST这样的请求有效负载，但也允许安全和幂等这样的GET。不幸的是，这一努力已经停滞，所以您可能不应该尝试现在使用搜索。

从技术上讲，该协议允许您在GET请求的情况下发送有效负载，但正如RFC 7231§4.3.1所指出的，这是不寻常的，可能会造成麻烦：

GET请求消息中的有效负载没有定义的语义；在GET请求上发送有效负载体可能会导致一些现有实现拒绝该请求。

Answer 2

在您的示例中，POST看起来在语义上不正确。也许您可以尝试查询类似的

GET -api/library/2/book/page?id=1，2，3，4，5