带正文的 REST API HTTP GET

Question

我实际上正在重写我们工作中的一些 API（在 ASP.Net Core 3.1 中），并尝试使它们成为 RESTFull。我遇到一些方法，应该使用 HTTP GET 调用它，因为它用于检索一些数据，但参数包装在一个相当大的 DTO 中。

所以我问自己如何应对：

• 让它把 DTO 放在 URL 中，但是大小有什么限制呢？
• 将正文放入 HTTP GET 请求中。我做了一些搜索，但发现的结果很旧。显然这是允许的，但当时不鼓励这样做
• 使用 HTTP Post，但它不是 REST，因为应该使用 POST 来创建数据

我认为更好的解决方案是将 HTTP Get 与 body 一起使用（根据这篇文章https://thecodebuzz.com/http-get-delete-request-body-guidelines/这是可能的）

有人遇到同样的问题吗？现在的指导方针是什么？

谢谢你的想法

Answer 1

\n

我认为更好的解决方案是将 HTTP Get 与 body 一起使用

\n

\n

RFC 7231不这么认为：

\n

\n

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

\n

\n

您不能指望通用组件对主体执行有用的操作。例如，缓存将使用 target-uri 作为主缓存键，并且根本不会考虑主体。所以很可能存在奇怪的行为。

\n

实际上，只有当您控制客户端、Web 服务器以及两者之间的组件时，带有主体的 GET 才会起作用。如果那样的话情况，您不妨使用您希望它具有的语义来定义您自己的 HTTP 方法。

\n

例如，您可能会查看HTTP SEARCH，看看这些语义是否更适合您想要做的事情。

\n

也就是说，如果您尝试在线条内着色，可以使用 POST。

\n

\n

POST 在 HTTP 中具有许多有用的用途，包括 \xe2\x80\x9c 的一般用途，此操作 \xe2\x80\x99 不值得标准化。\xe2\x80\x9d

\n

\n\n

\n

它不是 REST，因为应该使用 POST 来创建数据

\n

\n

REST 不定义任何类型的“创建”约束。REST 表示“使用统一接口中定义的适当方法”；HTTP 说“当没有更具体的方法适合时使用 POST”。

\n

但是，如果您处于一个不接受这一点的环境中……在不“违反规则”的情况下实现您想要的效果的一种方法是考虑创建一个新资源，该资源是您的查询结果。因此，我们 POST 一些信息，该信息与服务器控制的新 URI 相关联，然后后续尝试 GET 资源会得到您想要的结果。

\n

POST /foo\n\n201 Created\nLocation: /c30e910e-7baa-4c31-9481-4c84c12884a1  \n...Other Headers...\n\n

\n

GET /c30e910e-7baa-4c31-9481-4c84c12884a1\n\n200 OK\nContent-Location: /c30e910e-7baa-4c31-9481-4c84c12884a1\n...Other Headers...\n\nThe Answer\n

\n

遵循标准，您可以结合这两个想法来节省往返时间

\n

POST /foo\n\n201 Created\nLocation: /c30e910e-7baa-4c31-9481-4c84c12884a1  \nContent-Location: /c30e910e-7baa-4c31-9481-4c84c12884a1\n...Other Headers...\n\nThe Answer\n

\n

从那里，这是一小步

\n

POST /foo\n\n200 OK\n...Other Headers...\n\nThe Answer\n

\n

Answer 2

时至今日仍令人气馁。用于设计API定义的OAS3.0甚至不允许这样做。

您是否阅读过一些 REST 设计原则： Hackernoon 或风格指南Adidas API 指南 ？

他们将帮助您迈向安宁的道路。如果您有需要过滤的“集合资源”，请使用查询参数（如果它确实很复杂），那么它是搜索，在这种情况下通过“控制器资源”发布正文。

如果您想提供有关用例的更多详细信息，这里的人将很乐意提供帮助。