REST中的文件上传应该是他们自己的资源吗？

在REST体系结构中实现API时。我可以有一个名为Profile的资源，其中包含用户名和电子邮件。此外，我希望用户有一个个人资料照片。这应该是资源配置文件的一部分还是它自己的资源？

这取决于客户端如何使用API。你可以：

/api/profile/{id}

可能会返回，例如：

{
  "id": "1234",
  "name": "Dave Smith",
  "email": "d.s@test.com"
}

以及一个单独的照片API：

/api/profile/photo/{id}

无法返回个人资料照片的表示形式。REST是关于表示的，因此如果照片位于其自己的端点，则可以对其进行不同的表示：

/api/profile/photo/{id}/small
/api/profile/photo/{id}/medium
/api/profile/photo/{id}/large

将它作为一个单独的调用也意味着客户端在需要它之前不需要下载它。此外，在它自己的端点中，您可以更新它，而无需向服务器发送不必要的信息，例如配置文件数据（名称、电子邮件）

如果您想让客户轻松获取您可以在配置文件响应中使用的配置文件照片：

{
  "id": "1234",
  "name": "Dave Smith",
  "email": "d.s@test.com",
  "links": [
    {
        "photo": "/api/profile/photo/1234"
    }
  ]
}

尽管这是否有用还存在争议，因为客户无论如何都知道如何获取个人资料照片

如果您的业务模型规定配置文件必须有照片，要使用两个端点管理此情况，您需要首先上载配置文件照片，在返回中从API接收id，并使用该照片id创建新配置文件：

POST /api/users
    {
      "id": "1234",
      "name": "Dave Smith",
      "email": "d.s@test.com",
      "photo": "4567"
    }

但是如果档案照片所属的档案仍然存在，您的后端将需要阻止对档案照片执行

删除
操作

在REST体系结构中实现API时。我可以有一个名为Profile的资源，其中包含用户名和电子邮件。此外，我希望用户有一个个人资料照片。这应该是资源配置文件的一部分还是它自己的资源

当你浏览网页时，我想你会发现在大多数情况下，配置文件资源和配置文件图像资源是不同的。例如，在Twitter上（截至2019-07-23），使用与“配置文件”本身不同的URI访问“配置文件图像”。配置文件的HTML表示包括到配置文件图像的链接

如果配置文件和配置文件映像具有不同的缓存策略，那么这种方法将非常有意义

例如，在twitter的例子中，配置文件的更改要比配置文件图像频繁得多，因此将它们分开是有意义的

我认为，使概要照片成为同一资源的一部分，意味着要么使用照片作为资源的替代表示，要么将图像嵌入到资源的现有表示中。出于某些目的，这两个都可以吗？但是，在所有其他条件相同的情况下，我不希望它们比使用单独的资源更适合用途。
如果我在业务模型中定义了所有配置文件都必须有一张配置文件照片，该怎么办？我将如何使用2个资源来执行此操作？我已将该信息添加到答案中