设计rest web服务的最佳方法是从浏览器使用二进制数据

我正在开发一个json rest web服务，它将从使用backbone.js构建的单个网页应用程序中使用

此API将允许使用者上载与某些实体相关的文件，如与项目相关的pdf报告

在stack overflow上搜索并做一些研究，我得到了以下可能的方法：

第一种方法：base64编码数据字段

POST: /api/projects/234/reports
{
  author: 'xxxx',
  abstract: 'xxxx',
  filename: 'xxxx',
  filesize: 222,
  content: '<base64 encoded binary data>'
}

作为回应，我会得到一个报告id，然后我会发布另一个帖子

POST: /api/projects/234/reports/1/content
enctype=multipart/form-data

然后发送二进制数据

（看看这个：）

第三种方法：将二进制数据发布到单独的资源并保存href

首先，我在客户端生成一个随机密钥，并将二进制内容发布到那里

POST: /api/files/E4304205-29B7-48EE-A359-74250E19EFC4
enctype=multipart/form-data

然后

POST: /api/projects/234/reports
{
  author: 'xxxx',
  abstract: 'xxxx',
  filename: 'xxxx',
  filesize: 222,
  href: '/api/files/E4304205-29B7-48EE-A359-74250E19EFC4'
}

（见此：）

我只是想知道是否有其他方法可以使用，每种方法的优缺点，以及是否有任何既定的方法来处理此类需求

第一种方法的最大缺点是，我必须在客户机上完全加载并对文件进行base64编码

一些有用的资源：

POST: /api/projects/234/reports
{
  author: 'xxxx',
  abstract: 'xxxx',
}

---

我想不出任何其他的方法
在你的三种方法中，我使用的方法3最多。我看到的最大区别是第一种方法和另外两种方法之间的区别：将元数据和内容分为两种资源
• 优点：可伸缩性
  • 虽然您的解决方案涉及到发布到同一服务器，但这可以很容易地更改为将内容上载到单独的服务器（即Amazon S3）
  • 在第一种方法中，向用户提供元数据的同一台服务器将有一个进程被大型上载阻止
• 缺点：孤立数据/增加了复杂性
  • 上载失败（元数据或内容）将在服务器数据库中留下孤立数据
  • 孤立数据可以通过计划的作业进行清理，但这会增加代码的复杂性
  • 方法II减少了孤立的可能性，代价是当您阻塞第一个POST的响应时，客户端等待时间更长

---

第一种方法似乎是最容易编码的方法。但是，如果预期此服务不经常使用，并且您可以对用户文件上载设置合理的限制，我只会选择第一种方法。
我认为最终的方法是第3种（独立资源），主要原因是它允许最大化我从HTTP标准获得的价值，这与我对REST API的看法相匹配。例如，假设使用了一个基础良好的HTTP客户端，您将获得以下好处：
• 内容压缩：如果客户端表示支持，您可以通过允许服务器以压缩结果响应进行优化，您的API保持不变，现有客户端继续工作，未来的客户端可以使用它
• 缓存：如果自、ETag等被修改，客户端可以避免重新读取二进制数据
• 内容类型抽象：例如，您需要上传的图像，它可以是

  image/jpeg

  或

  image/png

  类型。HTTP头文件Accept和Content type为我们提供了一些优雅的语义，用于在客户端和服务器之间进行协商，而无需将其全部硬编码为模式和/或API的一部分
另一方面，我认为可以得出这样的结论：如果所讨论的二进制数据不是可选的，那么这种方法不是最简单的。在这种情况下，中列出的缺点将发挥作用。
我的研究结果：
• 单个请求（包括数据）
  请求包含元数据。数据是元数据的一个属性，并经过编码（例如：Base64）
  优点：
  • 交易的
  • 每次有效（无丢失的元数据或数据）
  缺点：
  • 编码使得请求非常大
  示例：
• 单个请求（多部分）
  请求包含一个或多个包含元数据和数据的部分
  内容类型：
  优点：
  • 交易的
  • 每次有效（无丢失的元数据或数据）
  缺点：
  • 内容类型协商是复杂的
  • 数据的内容类型在中不可见
  示例：
  • （包含用于数据和元数据的部件）
  • （一部分用于数据，仅元数据部分用于文件名和mime类型）
  • （一部分用于数据，无元数据）
  • （一部分用于元数据，一部分用于零件数据）
• 单个请求（HTTP头和URL中的元数据）
  请求主体包含数据和HTTP头，URL包含元数据
  优点：
  • 交易的
  • 每次有效（无丢失的元数据或数据）
  缺点：
  • 不可能有嵌套元数据
  示例：
  • S3和
• 两个请求
  一个元数据请求和一个或多个数据请求
  优点：
  • 可伸缩性（例如：数据请求可以转到存储库服务器）
  • 可恢复（参见示例）
  缺点：
  • 非交易性
  • 并非每次都有效（在第二次请求之前，缺少一部分）
  示例：