几次遇到需要创建RESTful-API的问题，但要求也指出“应该可以使用API上载文件”。在过去的几次中，我已经通过简单地允许客户端将包含文件内容的multipart / form-data发送到我的RESTful-API来解决了这个问题。但是，这种方法让我怀疑这是否是正确的方法去做吧。RESTful准则明确指出，您只能对一个单一资源进行CRUD，但是multipart / form-data的性质是多种资源（例如，多个文件..或一个文件和一堆元数据）等）。现在，我可以只是简单地将端点限制为只允许multipart / form-data中的一个“内容”，然后将其与正确的url相关联，但这会破坏multipart-content-type的用途。或者我可以允许多种资源的C（R）UD运算，或者我可以将整个请求视为一个单一资源（一个包含文件，元数据等的资源。但是，对于GET来说，获得与请求期间发送的内容相同的响应，因为据我所知您无法获取多部分/表单数据，但是您可以获取单个文件或单个JSON / XML等。）有没有人以“简洁”的方式解决这个问题，既与REST并存，又不会将multipart限制为一个“资源”？还是我不应该简单地不使用multipart并为文件使用其他内容，并且以这种方式能够分离文件上载和“ text / json / xml / etc-uploads”？
使用REST架构约束设计的主要应用程序是world wide web。
在网络上，上传文件的常见方法是使用HTML表单，其enctype设置为multipart / form-data，并且输入控件的类型为type = file。
任何通用组件都知道正确的做法，因为所有有用的位都已标准化-表单的超媒体表示形式（由服务器提供）定义了客户端构造适当的HTTP所需的所有参数。请求。
RESTful准则明确指出您只能对一个单一资源进行CRUD
REST受很多semantic diffusion困扰。当您开始尝试合并不同作者的想法时，它可能会使您感到困惑。
REST并不意味着CRUD-REST意味着所有资源都以相同的方式理解消息。
HTTP（再次符合REST约束）定义了许多不同的methods，供客户端在将预期语义传达给服务器时使用。对于远程创作语义GET，PUT（PATCH），DELETE，我们需要传达对文档的远程更改，但是HTTP的统一接口并不仅限于此-我们还有很多其他methods with standards。
当然，该列表包括POST，这并不意味着“ CRUD”。实际含义更接近这些semantics aren't worth standardizing。