当通过RESTful接口表示数据模型时，可以理解创建与一个类型/对象组相关联的顶级端点：
我们可以重新使用HTTP谓词来启用对这些组的操作（GET列表，POST创建等）。当表示具有“依赖性”的模型（即没有“父”时它不能存在）时，我们可以创建更深的端点来表示依赖关系：
在这种情况下，没有/tokens的顶级端点是有意义的，因为它们不应该在没有用户的情况下存在。
多对多关系变得有点棘手。如果两个模型可以具有多对多关系但也可以真正存在，那么为两个对象提供顶级端点和更深端点来定义关系是有意义的：
然后我们可以使用 PUT 和 DELETE 方法通过HTTP接口定义这些关系：PUT /users/[:user_id]/cars/[:car_id]。运行 PUT 操作会创建一个以某种方式链接两个对象的数据模型（如关系数据库中的连接表）。
然后，棘手的部分决定在何处限制界面以对抗冗余。
您是否允许对第二级深端点（GET /users/[:user_id]/cars/[:car_id]）发出 GET 请求？或者您是否要求他们从顶级GET /cars/[:id]访问“汽车”？
例如，如果我们想跟踪用户驾驶某辆汽车的次数怎么办？我们在哪里返回这些信息？如果我们在嵌套端点返回它，如果我们返回元信息而不是资源，我们是违反REST还是不一致？我们是通过某种属性将元信息嵌入到请求的资源中吗？
请指教。 ：P（但是真的，谢谢）
答案 0 :(得分：3)
您可以创建新资源。类似users/[:user_id]/cars/[:car_id]/stats的内容，其回复包含{drivings_count: 123}。你可能只允许这个资源的GET。
答案 1 :(得分：3)
此时恕我直言，这更像是个人设计偏好。
我个人会选择停在/ users / [：user_id] / cars /，然后要求拨打/ cars / [：car_id]来获取汽车信息。
如果您要包含特定于关系的元数据，例如“用户驾驶某辆车多少次？”将它保持在像/ users / [：user_id] / cars / [：car_id]这样更深层的关系中是有意义的。
说实话，这不是一门精确的科学。你必须做最简单，最具表现力但仍然足够强大的数据模型。