设计一个restful api：命名URI，自定义标头？

Question

编辑：我已经解决了我的问题（至少目前为止）。

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

假设我有一个示例restful Web服务处理租赁公寓应用程序，其中客户端使用Basic Auth（保持简单）进行身份验证。如下定义基本数据：

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

我正在努力为一般的Applications资源正确建模URI，更具体地说，就客户角色而言。 （假设api root为https://api.example.com/）

如何让房东获取发送给他们的应用程序列表？我的直觉说，请求“GET / applications”，Basic Auth让服务器知道为哪个用户构建列表;同样，Renter请求的“GET /应用程序”将返回他们发送的应用程序列表......但我不相信这是一个可靠的设计，通常可以在同一URI上混合和匹配发件人与收件人列表。我是否应该以不同的方式考虑“/ applications”资源，并且可能为每个用户提供类似“/ applications / [USER_IDENTIFIER]”的层次结构？

此外，无论我的应用程序URI设计如何，假设房东能够代表租客创建应用程序。这是通过发送PUT / POST创建请求的“X-Create-On-Behalf-Of：somerenter@example.com”等自定义标头来实现的吗？或者我的架构是否应该定义允许此替代方案的字段。

我非常喜欢这个，所以我对任何对我的假设/设计的批评，以及任何有关设计RESTful api的更多信息的指示都持开放态度。谢谢阅读。

Answer 1

我想我找到了解决方案。

斗地主和租房者实际上只是同一个对象的子类，我称之为Party（如交易的一方，而不是生日聚会）。那么每个人都有自己的资源，名为/ party / PARTY_ID。

很容易扩展它以查看/ party / SOME_LANDLORD / applications和/ party / SOME_RENTER / applications解决了我的问题。它还消除了我考虑自定义标头的需要。