GET请求发送查询参数的最佳实践是什么？

Question

我正在为我的应用程序编写后端，该后端将接受来自前端的查询参数，然后根据这些参数查询我的数据库。这听起来应该是一个GET请求，但由于我有很多参数要传递，其中一些是可选的，所以我认为最简单的方法是进行POST请求并在请求体中发送搜索参数。我知道我可以将我的参数转换为查询字符串并将其附加到我的GET请求中，但肯定有更好的方法，因为如果我这样做，我将传递不同的数据类型并最终不得不在后端解析参数。

- Justin Dunlap

Answer 1

这在很大程度上取决于上下文，但在您的情况下，我更喜欢使用GET请求。

我应该使用哪种请求方法

根据广为接受的惯例，可以使用：

• GET 读取现有数据
• POST 创建新内容

更多详细信息可以在此找到：https://www.restapitutorial.com/lessons/httpmethods.html

如何传递参数

关于传递参数的方式，这是一件不那么明显的事情。除非请求参数中有敏感信息，否则将其作为URL的一部分发送是完全可以的。

参数可以作为路径的一部分：

myapi/customers/123

或查询字符串：

myapi?customer=123

两种选择都可行，我认为选择取决于应用程序域模型。一个流行的经验法则是：

• 对于必填参数，请使用“参数作为路径的一部分”
• 对于可选参数，请使用“参数作为查询字符串”。

- Alexander Pushkarev

Answer 2

如果参数/选项很多，我建议使用POST。以下是我认为它比GET更好的几个原因：

• 您的URL看起来更干净
• 您可以向用户隐藏内部结构（如果他们使用浏览器的开发人员工具，仍然可见）
• 人们无法轻松更改选项以调整查询。在URL中将其修改并重新加载其他值很简单。作为POST这样做需要更多的工作。

但是，如果最终得到的URL可以被收藏或共享，则您需要将所有参数编码为查询的一部分，因此在这种情况下使用GET最好。

另一个答案声明应该使用POST来创建新内容，但我不同意。这可能适用于PUT，但即使检索现有数据时，使用POST也完全可以传递更复杂的结构。

例如，使用POST，您可以发送一个具有嵌套结构的JSON主体对象。这非常方便，而传统的GET查询很难实现。您还需要担心对数据进行URL编码，然后在接收时解码数据，这是一件麻烦的事情。

- Always Learning

---

在使用POST是可行的解决方案时，如果请求在技术上是一个获取操作（而不是创建或修改状态），则混合动词是一个有问题的选择。 - Maniaque

我同意这不是最理想的，但你认为有更好的方法吗？ - Always Learning

Answer 3

对于简单的前后端通信，你不需要一开始就使用REST，因为它针对的是服务器被许多客户端访问且这些客户端不在你的控制范围内，或者客户端需要访问大量不同的服务器并且应该能够与它们所有的都正常工作。如果你认为未来服务器可能会自由发展而无需担心破坏客户端，那么应该采用REST架构。然而，这些强大的特性也带来了开发成本和谨慎设计的代价。不要误解，你仍然可以采用REST架构，但是对于这样一个简单的应用程序-后端场景，这听起来像是过度设计。

在REST架构中，通常服务器会告诉客户端它希望如何接收输入数据。可以将HTML表单视为例子，其中method和enctype属性指定要使用哪个HTTP方法以及要转换为哪种表示格式的输入。要使用哪个HTTP方法取决于实际用例。如果服务器不断接收相同的请求以获取相同的输入参数，并且计算结果可能很昂贵，则缓存响应一次并从该缓存中提供进一步的请求可能会从服务器中消除许多不必要的计算开销。例如，BBC声称缓存是保持网站可扩展性和快速性的最重要技术。我曾经读到他们只缓存大多数文章一分钟，但这足以使他们免受反复检索相同内容成千上万次的困扰，从而释放资源用于其他请求或任务。毫无疑问，缓存也是REST的少数限制之一。

默认情况下，HTTP允许缓存存储请求URI（包括任何查询、路径或矩阵参数）的响应表示，如果通过安全操作请求，例如HEAD或GET请求。但是，任何调用不安全操作都将导致缓存失效，因此删除该目标URI的任何存储表示。因此，该URI的任何后续请求都将到达服务器，以便为请求客户端处理响应。

很遗憾，缓存并不是决定使用 GET 还是 POST 的唯一因素，客户端当前处理的表示格式也会影响决策。想象一下，一个客户端正在处理从服务器接收到的先前的HTML响应。HTML响应包含一个表单，教授客户端服务器期望的输入字段以及客户端可以为某些输入参数做出的选择。 HTML是一个完美的例子，其中媒体类型限制了可用的HTTP方法（默认方法为GET和支持POST），以及不支持的方法（所有其他HTTP方法）。其他表示格式可能仅支持POST（即使application/soap+xml允许使用GET或POST（至少在SOAP 1.2中），但我从未见过实际中的GET请求，因此所有内容都用POST交换）。

一个可能会阻止您使用GET请求的进一步要点是大多数HTTP实现中存在的URI长度的事实上的限制。如果您超过了这个限制，一些HTTP框架可能无法处理交换的消息。然而，在查看Web时，人们可能会发现一个小技巧来解决这种限制。在大多数Web商店中，结账区域通常分为不同的页面，每个页面都包含一个表单，收集一些输入，如地址信息、银行或付款数据和其他输入，作为整体充当向导，引导用户完成支付过程。这种向导风格也可以在这种情况下实现。请求的部分通过POST发送到专用端点，该端点负责收集数据，并在向导的最后一个“页面”上询问所收集数据的最终确认，并将其资源用作GET目标。这样，即使输入数据超过了一些HTTP框架强加的典型URL限制，响应仍然可缓存。

虽然Always Learning列出的论点没有错，但从安全角度来看，我不会依赖这些论点。虽然它可以过滤掉知识较少的人，但对于有知识的人（而且有很多人）在将请求发送到服务器之前进行修改，它不会长时间阻碍他们。因此，仅仅建议使用PUT作为使用户编辑更难的方法，对我来说感觉很奇怪。

因此，总的来说，我会基于响应是否可缓存（通常会请求）等因素，决定使用POST或GET将数据发送到服务器。在URI可能变得非常大以至于某些HTTP框架无法处理请求的情况下，您基本上被迫使用POST，除非您可以将实际请求拆分为多个更小的请求，这些请求充当数据收集的向导，直到最终确认请求触发实际的最终HTTP调用。

- Roman Vottner