设计一个 Restful api：命名 URI、自定义标头？
编辑：我已经解决了我的问题（至少现在）。
我最近一直在使用 Zendesk REST Api 及其对自定义“的使用”用于查找特定用户打开的票证的“X-On-Behalf-Of”标头让我思考 Restful Api 设计选择（没有特定的语言，更多的是如何命名 URI 的问题）。我还阅读了 有关自定义 HTTP 标头的相关问题，但它给我留下了问题多于答案。
假设我有一个处理出租公寓应用程序的宁静 Web 服务示例，其中客户端使用基本身份验证（保持简单）进行身份验证。定义基本数据如下：
- 用户（可以是房东或租户类型）
- 表单（由一个或多个文档资源和一些表单元数据（如表单名称和版本信息）组成）
- 然后是与租赁应用程序相对应的某种类型的资源，它将表格、申请人（一个或多个租户）、房东以及一些元数据（例如状态和日期）联系在一起。
我正在努力为应用程序资源正确建模 URI，更具体地说，针对客户端角色。 （假设 api 根目录是 https://api.example.com/）
我如何允许房东获取发送给他们的应用程序列表？我的直觉是向“GET /applications”发出请求，基本身份验证让服务器知道要为哪个用户构建列表；同样，承租人请求的“GET /applications”将返回他们已发送的应用程序列表...但我不相信这是一个可靠的设计，可以在同一 URI 上混合和匹配发件人和收件人列表。我是否应该以不同的方式考虑“/applications”资源，也许允许每个用户使用“/applications/[USER_IDENTIFIER]”这样的层次结构？
另外，无论我的应用程序 URI 设计如何，假设房东能够代表承租人创建应用程序。通过发送像“X-Create-On-Behalf-Of: [电子邮件受保护]" 与 PUT/POST 创建请求？或者我的模式应该定义一个允许这种替代方案的字段。
我对此非常业余，所以我愿意接受对我的假设/设计的任何批评，以及任何有关学习更多有关设计 RESTful api 的建议。感谢您的阅读。
EDIT: I've solved my issues (for now at least).
I've recently been working with the Zendesk REST Api and their use of the custom "X-On-Behalf-Of" header for looking up tickets opened by a particular user got me thinking about Restful Api design choices (in no specific language, more of a how to name URIs question). I've also read this related question on Custom HTTP headers, but it left me with more questions than answers.
Say I have an example restful web service dealing with rental apartment applications where clients use Basic Auth (keep it simple) to authenticate. Define the basic data as such:
- Users (can be of type landlord or renter)
- Forms (which consist of one or more Document resources and some form meta data like form name and version info)
- And then some type of resource corresponding to Rental Applications, which ties together Forms, Applicants (one or more renters), Landlord, and some metadata like status and dates.
I'm struggling to properly model the URIs for the Applications resource in general, and more specifically with respect to a clients role. (assume api root is https://api.example.com/)
How do I allow a Landlord to fetch a list of applications sent to them? My intuition says make a request to "GET /applications" and Basic Auth lets the server know which user to build the list for; likewise "GET /applications" requested by a Renter would return a list of applications they've sent...but I'm not confident this is a solid design in general to mix and match sender vs. recipient lists at the same URI. Should I be thinking about the "/applications" resource differently, and perhaps allowing a hierarchy like "/applications/[USER_IDENTIFIER]" for each user instead?
Also, regardless of my applications URI design, assume a Landlord is able to create an application on behalf of a renter. Is this better accomplished by sending a custom header like "X-Create-On-Behalf-Of: [email protected]" with the PUT/POST creation request? Or should my schema define a field which allows for this alternative scenario.
I'm very much an amateur at this, so I'm open to any criticism of my assumptions/design, as well as any pointers for learning more about designing RESTful api's. Thanks for reading.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我想我已经找到了解决方案。
房东和租客实际上只是同一对象的子类，我将其称为“派对”（作为交易的参与方，而不是生日聚会）。这样每个人就有自己的资源，命名为/party/PARTY_ID。
很容易扩展它以查看 /party/SOME_LANDLORD/applications 和 /party/SOME_RENTER/applications 解决我的问题。它还消除了我考虑自定义标头的需要。
I think I've found a solution.
Landlords and Renters are really just subclasses of the same object, which I'll call Party (as in party to a transaction, not birthday party). So then each one has their own resource, named like /party/PARTY_ID.
It's easy to extend this to see that /party/SOME_LANDLORD/applications and /party/SOME_RENTER/applications solve my issues. It also removes my need to consider custom headers.