【发布时间】：2021-09-15 13:51:23
【问题描述】：
想象一个简单的例子，比如实现了 CRUD 方法的“Vehicle Make and Model”REST API。
车辆制造与型号之间的关系是 1:N。一个汽车品牌可以有 N 个车型，但一个车型只关联一个品牌。
我们的 CRUD 方法：
- POST/PUT 车辆/品牌：创建或更新有关一个车辆品牌的基本信息。
- GET 车辆/品牌：获取车辆品牌列表。
- 获取车辆/品牌/{id}：获取特定车辆品牌及其信息。
- POST/PUT 车辆/品牌/{id}/models：创建或更新有关一种车辆模型的基本信息。
- GET vehicle/makes/{id}/models：获取特定品牌的车辆型号列表。
- GET vehicle/makes/{id}/models/{id}：获取特定品牌的特定车型。
问题是：
GET makes or makes/{id} 是否应该在其中返回他们的模型列表？或者，是否应该仅在特定请求中返回模型？
我必须考虑在我的 API 中返回或不返回嵌套信息？
这个例子很简单，但是场景可以通过很多层次依赖的方式进行扩展，比如：
车辆 ├── 车辆制造 │ ├── 车辆型号 │ └── ... ├── 轮胎 │ └── 轮胎品牌 │ ├── 轮胎模型 │ └── ... └── ... └── ...【问题讨论】：
-
我在一家公司工作，我们实际上有车辆查找服务，并且有类似的休息 API 格式。对我们来说，
vehicle/makes/{id}什么也不返回，它对我们来说不是一个有效的端点，因为没有任何特定于 make 的东西。您需要搜索模型以获取模型列表，因此您将执行vehicles/makes/{id}/models。有趣的是它应该是vehicle/make/{id}/models。还记得您请求的资源是 Singleton 还是 Collection？models将返回一个集合，model将返回一个单例。 -
也许您想查看
graphql，因为我猜图表更适合您的用例。 -
@Popeye 我试图保留其余的概念。一个好的做法是在资源路径上使用复数：good-restful-url-examples。
-
@Shahriar 不幸的是，
graphql不是该项目的选项；( -
我认为这是一个很好的问题，但是它征求的答案可能是基于意见的（SO 题外话），我想知道另一个 StackExchange 站点是否更合适（？）...这是我在考虑 REST API 时经常遇到的问题。