Rest 在POST上使用URL查询参数

我的团队需要构建一个用于上传文档（如PDF）的API。我的目标之一是让打电话的人尽可能无痛。我相信以流形式提供二进制内容的POST调用是最简单的。一名团队成员指出，需要随本文档一起提供元数据。他假设这将需要一个多部分mime请求。在我看来，这为服务的用户增加了大量的复杂性

我建议在URL的“查询字符串”中设置元数据。这允许元数据和文档的简单流解决方案。我们都相信，从技术角度来看，这应该是可行的，但他认为这是不标准的，或者可能不是宁静的

对我来说，这似乎是一个非常简单的解决方案，但我确实找不到任何关于这是否有问题的明确答案。我发现了一些关于这方面的讨论，但答案似乎都转向了“混合获取和发布”，而我根本没有遵循这一点。除非我遗漏了什么，否则这与GET无关，只是POST以及该POST的URL是如何构造的。似乎有一种观点认为查询参数只受GET支持，但我不认为是这样

---

有人能就此提供权威参考吗？

这取决于你所说的“有问题”是什么意思。从可用性的角度来看，它可能没有什么问题。请记住，REST是一种体系结构样式，有关样式的权威参考可能与样式本身一样主观。您可以找到一个关于您正在使用的传输协议HTTP的权威参考，但是什么时候偏离协议会有问题，什么时候它仅仅是针对纯粹主义的？阅读RFC7230和7231，并尝试找出答案

换句话说，我的意思是，如果你想找一个权威消息来源来解决与同事的争论，我认为你不会找到它

如果您只是想澄清一下，那么从REST的角度来看，URI是资源的原子标识符。查询参数是标识符的一部分，但由于它们是原子的，所以它们的语义是无关的。这意味着任何关于URI是否是RESTful的讨论都是毫无意义的。只要URI指向一个且仅指向一个资源，并且它不是从带外信息获取的，它就是RESTful的，不管其内容如何。当然，您应该尝试使用易于理解的有意义且简单的URI，但这是HTTP上的一般最佳实践，而不是REST约束

在您的案例中，真正的问题是POST方法的语义是根据预定义的规则提交由URI标识的资源处理的有效负载。您在文章中使用的URI并没有标识您正在上载的文件，而是标识负责上载的资源。如果您在URI中包含用于处理的元数据，那么实际上就是说每个PDF文件都是使用不同的上传器资源上传的。从REST的角度来看，这本身并没有什么问题，但从HTTP和可用性的角度来看，这很奇怪。我希望每个人都使用相同的资源，并在有效负载中提供额外的数据。在这一点上，我认为您的同事是正确的，您应该使用多部分mime请求，或允许您将pdf文件和元数据打包到有效负载中的媒体类型格式

---

然而，如果您的元数据在上传PDF文件后没有改变——或者换句话说，如果您的URI没有改变——那么使用PUT方法就完全可以了。与POST方法不同，PUT不提交要由URI标识的资源处理的有效负载，而是要求服务器用有效负载中包含的资源替换URI中的资源。在本例中，URI确实标识了PDF文件，因此只要这不会改变就可以了。

我非常感谢您花时间提供如此精心编写和深思熟虑的响应。我想我会一直跟踪你直到这一点“你实际上是说每个PDF文件都是用不同的上传资源上传的”。我不认为我理解您在这个上下文中使用术语“uploader resource”的人。为了进一步解释这个场景，对于正确性至关重要的是，在这种情况下，URI是由API创建的，因此PUT是不可能的。这里的元数据主要用于标记文档，以便在搜索中找到它们。它们对URI或资源的内容没有影响。URI是原子的。查询字符串不是“参数”，它们是URI的一部分。POST方法将有效负载提交给目标资源，因此每个PDF文件都由不同的URI处理，因此您要么有不同的资源执行相同的操作，要么有无数不同的URI引用相同的资源。如果PUT是不可能的，那么我同意您的同事的看法。您应该使用POST和允许在有效负载中提交文件和元数据的媒体类型。我不怀疑你在这里是正确的，但我对这一点的实用性有些怀疑。我在这里遇到的一个问题是，查询字符串通常被称为“参数”。有趣的是，我的搜索所构建的URI包含了许多其他元素：“&oq=query+string+parameters&aqs=chrome..6i57.62j0j8&sourceid=chrome&es_sm=122&ie=UTF-8”，这些元素似乎对搜索返回的结果没有影响。