【发布时间】：2018-07-09 19:51:33
【问题描述】：
希望是一个快速的问题：
如果我有一辆可以出租的汽车，我会使用哪条路线来查看汽车预订：
/bookings/car/:carID
或者
/cars/:carID/bookings
我可以看到这两种方法是如何工作的，但哪种方法更好，因为它返回的预订应该是通过 Booking 端点而不是 Car 端点。
我认为导航到 Car 端点然后进入预订会更好读。
【问题讨论】：
【发布时间】：2018-07-09 19:51:33
【问题描述】：
正确的选择是：/cars/:carID/bookings
这里引用文章（使用您的示例）RESTful API Designing guidelines — The best practices 的原因：
[...] 如果我们有资源下的资源，例如汽车的预订， 那么一些示例 API 端点将是：
GET /cars/3/bookings应该会得到3号车的所有预订列表GET /cars/3/bookings/45应该得到预订 45 的详细信息，属于 3 号车DELETE /cars/3/bookings/45应该删除booking 45，属于3号车POST /cars/3/bookings/应该为 3 号车创建一个新预订并返回新创建的预订的详细信息
这是另一篇关于 RPC 和 RESTful 服务之间区别的精彩文章，其中也有很好的示例：Understanding RPC Vs REST For HTTP APIs
这是那篇文章的结论（文章的主要部分有太多要引用的内容）：
一个简单的经验法则是：
- 如果一个 API 主要是动作，也许它应该是 RPC。
- 如果 API 主要是 CRUD 并且正在操作相关数据，那么它可能应该是 REST。
如果两者都不是明显的赢家怎么办？您选择哪种方法？
同时使用 REST 和 RPC 链接
您需要选择一种方法并且只有一个 API 的想法是 有点假。一个应用程序可以很容易地拥有多个 不被视为“主要”API 的 API 或附加服务。 使用任何公开 HTTP 端点的 API 或服务，您都可以 在遵循 REST 或 RPC 规则之间进行选择，也许你会 有一个 REST API 和一些 RPC 服务。
了解 REST 和 RPC 之间的区别非常有用 当你计划一个新的 API 时，它真的可以帮助你 处理现有 API 的功能。最好不要混搭风格 一个单一的 API，因为这可能会让消费者感到困惑 您的 API 以及任何需要一组约定的工具 （例如 REST），当它看到一个 不同的约定（RPC）。在有意义时使用 REST，或者 如果更合适，请使用 RPC。或者同时使用并拥有最好的 两个世界！
【讨论】：
-
非常有帮助。是的，我可以看到逻辑，这就是我在上下文中阅读时的想法。问题是预订中还包含一名司机。所以预订包括汽车和司机。所以 /car/5/bookings 将只接受 GET 请求，POST 将被发送到 /bookings ，DELETE 和 PATCH 将被发送到 /bookings/:bookingID
-
@Michael 在预订有司机
POST car/3/bookings的汽车时只需要司机作为参数之一。如果您不小心，如果您需要查询任何汽车的司机预订driver/9/bookings，事情可能会开始变得一团糟？甚至是过去一天的所有预订bookings?period=1d？但是，如果您也想按驱动程序进行过滤，bookings?period=1d&driver=9那么bookings?driver=9也应该可以工作，不是吗？以我的经验，重构代码以避免代码重复。同一件事的多个端点很好。只要保持一切井井有条/合乎逻辑/干净。 -
是的，太好了！谢谢你，现在已经说清楚了。