多部分/表单数据和RESTful体系结构？

Question

有几次我遇到了一个需要创建RESTful API的问题，但是需求中也指出“应该可以使用API上传文件”。。在过去的几次中，我通过简单地允许客户端将包含文件内容的多部分/表单数据发送到我的RESTful API来解决这个问题。。然而因此，这种方法让我怀疑这是否是正确的方法。RESTful指南明确指出，您应该只能对一个资源进行CRUD，但多部分/表单数据的性质是多个资源（例如，1个多文件..或1个文件和一组元数据，等等）。现在，我可以简单地将endpoint限制为在多部分/html" target="_blank">表单数据中只允许一个“内容”，然后将其与正确的url关联，但这会破坏多部分内容类型的用途。。或者我可以允许多个资源的C（R）UD操作，或者我可以将整个请求视为一个单一资源（一个包含文件、元数据等的资源。但是，对于GET，不可能获得与请求期间发送的内容相同的响应，因为据我所知，您无法获得多部分/表单数据，但您可以获得单个文件或单个JSON/XML等）有没有人以一种“简洁”的方式解决了这个问题，既与REST相结合，又不将多部分限制为一个“资源”？或者我不应该简单地使用multipart并对文件使用其他东西，这样就可以将文件上传和“text/json/xml/etc上传”分开？

Answer 1

REST是一种架构风格。

使用REST架构约束设计的主要应用程序是万维网。

在网络上，上传文件的一种常见方法是使用超文本标记语言表单，将enctype设置为Multipart/form-data，以及使用type=file的输入控件。

任何通用组件都知道应该做什么，因为所有有用的位都已标准化——表单的超媒体表示（由服务器提供）定义了客户端构造适当HTTP请求所需的所有参数。

RESTful指南明确指出，您应该只能对单个资源进行CRUD

REST受到大量语义扩散的影响。当你开始试图将不同作者的想法结合起来时，事情会变得非常混乱。

REST并不意味着CRUD-REST意味着所有资源都以相同的方式理解消息。

HTTP（同样符合REST约束）定义了许多不同的方法，供客户端在向服务器传递预期语义时使用。对于远程创作语义，GET、PUT（PATCH）、DELETE是我们向文档传递远程更改所需的全部内容，但HTTP的统一接口并不止于此——我们还有许多其他标准方法。

当然，这个列表包括POST，这并不意味着“CRUD”。实际意义更接近这些语义学，不值得标准化。