【发布时间】：2011-10-25 17:47:48
【问题描述】：
编辑：我已经解决了我的问题（至少现在）。
我最近一直在使用 Zendesk REST Api，他们使用自定义的“X-On-Behalf-Of”标头来查找特定用户打开的票证，这让我想到了 Restful Api 设计选择（在没有特定语言，更多的是如何命名 URI 的问题）。我也读过this related question on Custom HTTP headers，但它给我留下的问题多于答案。
假设我有一个示例 RESTful Web 服务处理出租公寓应用程序，其中客户端使用基本身份验证（保持简单）进行身份验证。定义基本数据如下：
- 用户（可以是房东或租客类型）
- 表单（包含一个或多个文档资源和一些表单元数据，如表单名称和版本信息）
- 然后是与租赁申请相对应的某种类型的资源，它将表格、申请人（一个或多个租户）、房东以及一些元数据（如状态和日期）联系在一起。
我正在努力为应用程序资源的 URI 正确建模，尤其是在客户端角色方面。 （假设 api 根是 https://api.example.com/）
我如何允许房东获取发送给他们的申请列表？我的直觉是向“GET /applications”发出请求，Basic Auth 让服务器知道要为哪个用户构建列表；同样，Renter 请求的“GET /applications”将返回他们已发送的应用程序列表......但我不相信这是一个可靠的设计，可以混合和匹配同一 URI 中的发件人和收件人列表。我是否应该以不同的方式考虑“/applications”资源，并且可能允许为每个用户使用像“/applications/[USER_IDENTIFIER]”这样的层次结构？
此外，无论我的应用程序 URI 设计如何，假设房东能够代表租户创建应用程序。通过使用 PUT/POST 创建请求发送自定义标头（例如“X-Create-On-Behalf-Of: somerenter@example.com”）是否可以更好地完成此操作？或者我的架构是否应该定义一个允许这种替代方案的字段。
我在这方面非常业余，所以我愿意接受任何对我的假设/设计的批评，以及任何关于学习更多关于设计 RESTful api 的指针。谢谢阅读。
【问题讨论】：
-
在考虑使用 x- 标头之前，请阅读此tools.ietf.org/html/draft-saintandre-xdash-03
-
+1 for @DarrelMiller ，甚至没有考虑 X-header 问题。