api - 设计一个 Restful api : naming URIs, 自定义 header ？

Question

编辑:我已经解决了我的问题(至少现在)。

我最近一直在使用 Zendesk REST Api以及他们使用自定义“X-On-Behalf-Of” header 来查找特定用户打开的票证让我想到了 Restful Api 设计选择(没有特定的语言，更多的是如何命名 URI 的问题)。我也读过 this related question on Custom HTTP headers ，但这给我留下的问题多于答案。

假设我有一个处理出租公寓应用程序的 Restful Web 服务示例，其中客户端使用 Basic Auth(保持简单)进行身份验证。定义基本数据:

• 用户(可以是房东或租客类型)
• 表单(由一个或多个文档资源和一些表单元数据(如表单名称和版本信息)组成)
• 然后是与租赁申请相对应的某种类型的资源，它将表格、申请人(一个或多个租户)、房东以及一些元数据(如状态和日期)联系在一起。

我正在努力为一般的应用程序资源正确建模 URI，更具体地说，关于客户角色。 (假设 api 根是 https://api.example.com/ )

我如何允许房东获取发送给他们的申请列表？我的直觉是向“GET/applications”发出请求，Basic Auth 让服务器知道为哪个用户构建列表；同样，承租人请求的“GET/applications”将返回他们已发送的应用程序列表……但我不相信这是一个可靠的设计，通常可以在同一 URI 中混合和匹配发件人与收件人列表。我是否应该以不同的方式考虑“/applications”资源，或许允许每个用户使用“/applications/[USER_IDENTIFIER]”这样的层次结构？

此外，无论我的应用程序 URI 设计如何，假设房东能够代表承租人创建应用程序。这是否通过发送带有 PUT/POST 创建请求的自定义 header (如“X-Create-On-Behalf-Of: somerenter@example.com”)更好地实现？或者我的模式是否应该定义一个允许这种替代方案的字段。

我在这方面非常业余，所以我愿意接受任何对我的假设/设计的批评，以及任何关于学习更多关于设计 RESTful api 的指导。谢谢阅读。

Answer 1

我想我已经找到了解决方案。

Landlords 和 Renters 实际上只是同一对象的子类，我将其称为 Party(作为交易的一方，而不是生日派对)。所以每个人都有自己的资源，命名为/party/PARTY_ID。

扩展它很容易看到/party/SOME_LANDLORD/applications 和/party/SOME_REENTER/applications 解决了我的问题。它还消除了我考虑自定义 header 的需要。