6

我正在尝试在 REST 中对实体的附件进行建模。假设一个缺陷实体可以附加多个附件。每个附件都有一个描述和一些其他属性（最后修改，文件大小......）。附件本身是任何格式的文件（jpeg、doc ...）

我想知道我应该如何对它进行 RESTful 建模

我考虑了以下两个选项：

第一种方法（使用相同的资源，不同的表示）：

  • GET , content-type:XML on http://my-app/defects/ {id}/attachments将以 XML 格式返回缺陷的附件元数据（描述、上次修改、文件大小...）

  • GET , content-type:gzip on http://my-app/defects/ {id}/attachments将在 zip 文件中返回缺陷的附件

  • GET , content-type:mime multi-part on http://my-app/defects/ {id}/attachments将在多部分消息中返回缺陷的附件（二进制数据和 XML 元数据）

  • POST, content-type:XML on http://my-app/defects/ {id}/attachments将创建新附件，元数据只有没有附加文件（然后用户必须发送带有二进制数据的 PUT 请求）

  • POST , content-type:mime\multi-part on http://my-app/defects/ {id}/attachments将创建附件，客户端可以在一次往返中发送元数据和文件本身

第二种方法（将附件的数据与元数据分开）：

  • GET , content-type:XML on http://my-app/defects/ {id}/attachments将以 XML 格式返回缺陷的附件元数据（描述、上次修改、文件大小...）

  • GET , content-type:gzip on http://my-app/defects/ {id}/attachments/files将在单个 zip 中返回缺陷的附件二进制数据

创建一个新附件，首先调用：

  • POST, content-type:XML on http://my-app/defects/ {id}/attachments将创建新附件，元数据只有没有附加文件（然后用户必须发送带有二进制数据的 PUT 请求）

然后添加二进制数据本身：

  • POST , content-type:mime\multi-part on http://my-app/defects/ {id}/attachments/{id}/file将创建附件文件

一方面，第一种方法更加健壮和高效，因为客户端可以在单次往返中创建\获取附件元数据和二进制数据。另一方面，我有点不愿意使用 mime-multipart 表示，因为它的消费和生产更麻烦。

编辑：我检查了闪烁上传 REST API。似乎他们正在使用多部分消息来包含照片和照片属性。

4

2 回答 2

3

Atom Pub 规范已经解决了这个问题的大部分。看这里

在您提出的解决方案中需要注意的一件事是您正在使用内容协商来交付不同的内容。我相信这被认为是不好的。内容协商应该只提供相同内容的不同表示。

于 2009-10-08T13:03:05.617 回答
2

不要单独管理元数据。由两部分组成的动作违背了 REST 的观点。

一个平滑的 GET/POST/PUT/DELETE 和一个 - 相对 - 复杂的有效负载是通常所做的。

它是“表”中的多个底层“对象”这一事实与 REST 无关。

在 REST 级别，它只是通过一条消息传输的一个复杂对象的状态。

于 2009-10-08T10:35:25.517 回答