带有URL查询参数的HTTP POST-好主意吗？[关闭]

我正在设计一个通过HTTP的API，我想知道是否使用HTTP POST命令，但仅使用URL查询参数，而没有请求主体，是一种不错的方法。

注意事项：

• “良好的Web设计”要求通过POST发送非幂等动作。这是非幂等的动作。
• 当请求参数出现在URL中时，开发和调试该应用程序会更加容易。
• 该API并非旨在广泛使用。
• 似乎没有主体地发出POST请求将花费更多的工作，例如Content-Length: 0必须显式添加标头。
• 在我看来，没有主体的POST有点违反大多数开发人员和HTTP框架的期望。

通过URL查询而不是请求正文在POST请求上发送参数是否还有其他陷阱或优势？

编辑：正在考虑的原因是该操作不是幂等的，并且具有除检索之外的副作用。参见HTTP规范：

特别是，已经建立了约定，即GET和HEAD方法不应具有除检索之外的其他任何操作。这些方法应该被认为是“安全的”。这允许用户代理以特殊方式表示其他方法，例如POST，PUT和DELETE，以便使用户知道请求了可能不安全的操作这一事实。

...

方法还可以具有“幂等”的特性，因为（错误或过期问题除外）N> 0个相同请求的副作用与单个请求的副作用相同。GET，HEAD，PUT和DELETE方法共享此属性。同样，方法OPTIONS和TRACE不应有副作用，因此本质上是幂等的。

如果您的操作不是幂等的，则必须使用POST。如果不这样做，您只是在寻求麻烦。 GET，PUT并且DELETE方法必须是幂等的。想象一下，如果客户端预取GET了对服务的所有可能请求，应用程序中会发生什么–如果这会导致客户端可见副作用，那么出问题了。

我同意发送POST带有查询字符串但不带正文的似乎很奇怪，但是我认为在某些情况下它是合适的。

将URL的查询部分视为对资源的命令，以限制当前请求的范围。通常，查询字符串用于对GET请求进行排序或过滤（如?page=1&sort=title），但我认为它对a POST也要限制范围（例如?action=delete&id=5）是有意义的。

每个人都是正确的：对于非幂等请求，坚持使用POST。

如何同时使用URI查询字符串和请求内容呢？好吧，它是有效的HTTP（请参阅注释1），为什么不呢？

这也是完全合理的：URL（包括查询字符串部分）用于查找资源。HTTP方法动词（POST-及其可选的请求内容）用于指定操作或处理资源。这些应该是正交的关注。（但是，对于ContentType = application / x-www-form-urlencoded的特殊情况，它们并不是完美的正交关系，请参阅下面的注释2。）

注意1：HTTP规范（1.1）没有声明查询参数和内容对于接受POST或PUT请求的HTTP服务器是互斥的。因此，任何服务器都可以自由接受两者。即，如果您编写服务器，则没有什么可以阻止您选择接受两者（可能是不灵活的框架除外）。通常，服务器可以根据其所需的任何规则解释查询字符串。它甚至可以使用条件逻辑来解释它们，这些条件逻辑也引用其他标头，例如Content-Type，这导致注释2：

注意2：如果Web浏览器是人们访问您的Web应用程序的主要方式，而application / x-www-form-urlencoded是他们发布的Content-Type，那么您应该遵循该Content-Type的规则。而且application / x-www-form-urlencoded的规则更加具体（坦率地说，很不寻常）：在这种情况下，您必须将URI解释为一组参数，而不是资源位置。[这与Powerlord提出的有用点相同；可能很难使用网络表单将内容发布到您的服务器。只是有所不同。]

注意3：查询字符串最初是做什么用的？RFC 3986将HTTP查询字符串定义为URI部分，它作为非分层方式定位资源。

万一提出这个问题的读者想问什么是好的RESTful体系结构：RESTful体系结构模式不需要URI方案以特定方式工作。RESTful体系结构将自身与系统的其他属性相关联，例如资源的可缓存性，资源本身的设计（其行为，功能和表示形式）以及是否满足幂等性。换句话说，就是实现一种与HTTP协议及其HTTP方法动词集高度兼容的设计。:-)（换句话说，RESTful体系结构对于资源的位置不太合适。）

最后要注意的是：有时查询参数还用于其他用途，既不查找资源也不编码内容。是否曾经见过像'PUT = true'或'POST = true'这样的查询参数？这些是不允许您使用PUT和POST方法的浏览器的解决方法。虽然这样的参数被视为URL查询字符串（上线）的一部分，我认为他们不是URL的查询的一部分精神。

你想要理由吗？这是一个：

Web表单不能用于将请求发送到使用GET和POST混合使用的页面。如果将表单的方法设置为GET，则所有参数都在查询字符串中。如果将表单的方法设置为POST，则所有参数都在请求正文中。

资料来源：HTML 4.01标准，第17.13节表格提交

从程序的角度来看，对于客户端，它打包参数并将其附加到url上，并执行POST与GET。在服务器端，它从查询字符串而不是发布的字节中评估入站参数。基本上是洗。

可能有优点/缺点的地方可能是特定的客户端平台如何与它们的网络堆栈中的POST和GET例程一起使用，以及Web服务器如何处理这些请求。根据您的实现，一种方法可能比另一种更为有效。知道这一点将指导您在这里做出决定。

但是，从程序员的角度来看，我更喜欢允许正文中包含所有参数的POST或url中具有所有参数的GET，并明确地忽略任何POST请求的url参数。它避免了混乱。

我认为让查询参数标识URL上的资源，同时将内容有效载荷限制在POST正文中，可能仍然非常RESTful。这似乎将“我要发送什么？”的考虑分开。而不是“我要寄给谁？”。

该REST阵营有一定的指导原则，我们可以用它来规范我们使用HTTP动词的方式。当您正在构建RESTful API时，这将很有帮助。

简而言之：GET应该是只读的，即对服务器状态没有影响。POST用于在服务器上创建资源。PUT用于更新或创建资源。DELETE用于删除资源。

换句话说，如果您的API操作更改了服务器状态，则REST建议我们使用POST / PUT / DELETE，但不要使用GET。

用户代理通常都知道执行多个POST是不好的，因此会发出警告，因为POST的目的是更改服务器状态（例如，在结帐时付款），并且您可能不想重复两次！

与您可以随意执行的GET（幂等）进行比较。

我同意-如果您只是在URL中而不是在正文中传递数据，则使用GET请求可能更安全。有关整个POST + GET概念的其他一些观点，请参见此类似问题。