我的团队需要构建一个用于上传文档的API，例如PDF文件。我的目标之一是尽可能让呼叫者尽可能轻松。我相信使用作为流提供的二进制内容的POST调用是最直接的。一名团队成员指出，需要提供元数据以及本文档。他认为这需要多部分mime请求。在我看来，这为服务的用户增加了大量的复杂性。
我建议在＆＃39;查询字符串中设置元数据＆＃39;的URL。这允许元数据和文档的简单流解决方案。我们都相信这应该从技术角度来看，但他认为这是非标准的或可能不是RESTful。
这对我来说似乎是一个非常直接的解决方案，但我确实无法找到关于这是否有问题的明确答案。我发现了一些似乎与此有关的讨论，但答案似乎都转向了混合GET和POST＆＃34;我根本不关注。除非我遗漏了某些内容，否则这与GET无关，只是POST以及该POST的URL是如何构建的。似乎只有GET支持查询参数，但我不相信这种情况。
有人可以就此提供权威参考吗？
答案 0 :(得分：2)
这取决于“有问题”的含义。从可用性的角度来看，它可能没有任何问题。请记住，REST是一种建筑样式，对样式的权威引用可以像样式本身一样主观。你可以找到关于你正在使用的传输协议的权威参考，HTTP，但是什么时候偏离协议有问题，什么时候它只是反对纯粹主义？阅读RFC 7230和7231并尝试弄清楚。
换句话说，我是说如果你是一个权威的来源与你的同事解决争执，我认为你不会找到它。
如果您只想澄清它，从REST角度来看，URI是资源的原子标识符。查询参数是标识符的一部分，但由于它们是原子的，因此它们的语义无关紧要。这意味着任何有关URI是否为REST的讨论都是毫无意义的。只要URI指向一个且只有一个资源且它不是从带外信息中获取的，它就是RESTful，无论其内容如何。当然，您应该尝试使用易于理解的有意义且简单的URI，但这是对HTTP的一般最佳实践，而不是REST约束。
在您的情况下，真正的问题是POST方法的语义是在预定义规则下提交由URI标识的资源处理的有效负载。您在POST中使用的URI不会标识要上载的文件，而是标识负责上载的资源。如果要在URI中包含要处理的元数据，则实际上是说每个PDF文件都使用不同的上载器资源上载。从REST的角度来看，这没有什么本质上的错误，但从HTTP和可用性的角度来看它很奇怪。我希望每个人都可以使用相同的资源，并且有效负载中会有其他数据。在这一点上，我认为你的同事是正确的，你应该使用多部分mime请求，或媒体类型格式，允许你将pdf文件和元数据打包在有效载荷中。
但是，如果您的元数据在上传PDF文件后没有改变 - 换句话说，如果您的URI没有改变 - 使用PUT方法完全可以。与POST方法不同，PUT不提交由URI标识的资源处理的有效负载，但要求服务器将URI中的资源替换为有效负载中包含的资源。在这种情况下，URI确实标识了PDF文件，所以没关系，只要它不会改变。