RESTful设计 - 如何为实体的附件建模

Question

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

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

我想到了以下两个选项：

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

• GET，内容类型： http://my-app/defects/ {id} / attachments 上的XML将返回缺陷 XML格式的附件元数据（描述，最后修改，文件大小......）

• GET，内容类型： http://my-app/defects/ {id} / attachments 上的gzip会在zip文件中返回缺陷的附件

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

• POST，内容类型： http://my-app/defects/ {id} / attachments 上的XML会创建新的附件，元数据只会附加文件（然后用户必须发送PUT请求）使用二进制数据）

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

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

• GET，内容类型： http://my-app/defects/ {id} / attachments 上的XML将返回缺陷 XML格式的附件元数据（描述，最后修改，文件大小......）

• GET，内容类型： http://my-app/defects/ {id} / attachments / files 上的gzip会在单个zip中返回缺陷的附件二进制数据

创建新附件，首先致电：

• POST，内容类型： http://my-app/defects/ {id} / attachments 上的XML会创建新附件，元数据只会附加文件（然后用户必须使用二进制文件发送PUT请求）数据）

然后添加二进制数据：

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

---

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

编辑：我签出了flicker upload REST API。他们似乎正在使用多部分消息来包含照片和照片属性。

Answer 1

Atom Pub规范已经解决了很多这个问题。见here

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

Answer 2

不要单独管理元数据。一个由两部分组成的行动打破了REST的重点。

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

“桌子”中的多个底层“对象”这一事实与REST无关。

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