REST Api 端点获取多个资源

Question

下面的操作仅检索请求中的所有书籍。这显然是一个 GET 操作。

从您的角度来看，执行以下两个操作更好(赞成/反对):

• 注意:

GET - api/library/2/books/

从图书馆 2 中检索所有书籍。

• 使用 GET:

GET - api/library/2/books/3/5/10/33/...../pages

• 使用 POST:

POST - api/library/2/books/pages

正文:

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

我真的很怀疑是使用 POST 还是 GET 方法来实现它。如果要检索 100-200 本书，URL 上的图书 ID 会变得非常困惑。我想在这里得到一些启发。

我正在使用 PHP 来处理 Rest 应用程序，并且上述所有这些方法都是有效的。

Answer 1

此操作符合 GET 的标准语义方法，因此对各种软件的期望。例如:

• 许多 HTTP 客户端都知道它们可以在出错时自动重试 GET 请求
• 更容易缓存对 GET 的响应

如果您的图书 ID 独立于图书馆 ID，那么最好删除对图书馆的引用，而只做

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

Books Ids on URL will get really messy if there was like 100-200 books to retrieve

如果每个图书 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 中定义作为一种“包罗万象”的方法:

process the representation enclosed in the request according to the resource's own specific semantics. For example, POST is used for the following functions (among others):

o Providing a block of data, such as the fields entered into an HTML form, to a data-handling process;

出于好奇，最近有人尝试 standardize a SEARCH method这将允许像 POST 这样的请求有效负载，但也可以是 safe和 idempotent喜欢得到。不幸的是，这项努力已经停滞，因此您现在可能不应该尝试使用 SEARCH。

从技术上讲，该协议(protocol)允许您使用 GET 请求发送有效负载，但作为 RFC 7231 § 4.3.1注意，这是不寻常的，可能会引起麻烦:

A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request.