我对如何组织API路由结构有疑问。已经阅读了许多关于构建RESTful API的书籍,但却无法找到答案。
每本书都讲述了简单的CRUD操作,以及一个级别的嵌套资源。
与/users
和/users/1/posts
一样。没问题。
示例:
但让我们看一下现实生活中更难的例子:
GET /cars // List of cars
GET /cars/{car_id} // Get single car
POST /cars // Add new car
PUT /cars/{car_id} // Update existing car
DELETE /cars/{car_id} // Delete car by specified ID
cars
的数据库表的结构将是
Table "cars"
- id
- uuid
- make
- model
- year
- created_at
- updated_at
- deleted_at
到目前为止没有问题,但后来我需要添加嵌套资源。 所有使用指定车辆进行的维修。
GET /cars/{car_id}/repairs // List of repairs that were done with car
GET /cars/{car_id}/repairs/{repair_id} // Get single repair
POST /cars/{car_id}/repairs // Add new repair for specified car
PUT /cars/{car_id}/repairs/{repair_id} // Update existing repair for specified car
DELETE /cars/{car_id}/repairs/{repair_id} // Delete repair by specified ID
数据库表的结构将是
Table "car_repairs"
- id
- uuid
- car_id ( foreign key to cars )
- title
- description
- repair_started_at
- repair_ended_at
- created_at
- updated_at
- deleted_at
到目前为止没问题。像所有书籍一样。 /users
路由和嵌套路由/users/1/posts
。但是当我需要添加另一个嵌套级别时,这就开始出现问题了。
我需要CRUD路线来解决汽车维修时发现的所有缺陷
GET /cars/{car_id}/repairs/{repair_id}/defects // List of all defects that were found for specified repair for speicified car
GET /cars/{car_id}/repairs/{repair_id}/defects/{defect_id} // Get single defect
POST /cars/{car_id}/repairs/{repair_id}/defects // Add new defect
PUT /cars/{car_id}/repairs/{repair_id}/defects/{defect_id} // Update existing defect
DELETE /cars/{car_id}/repairs/{repair_id}/defects/{defect_id} // Delete existing defect
表结构将是:
Table "car_repair_defects"
- id
- uud
- car_id
- repair_id
- name
- description
- created_at
- updated_at
- deleted_at
QUESTSIONS:
这里做什么,是.../defects
正常练习的水平?
考虑情况,如果我需要添加另一个第4级嵌套,例如,用于找到缺陷的所有部分
在RESTful API中嵌套资源时的最佳实践
可以说这可以在没有嵌套的情况下完成。示例/cars
/repairs
/defects
/parts
但是,那么,嵌套资源的RESTful示例又如何呢?那么什么是嵌套资源0,1,2,3?
此外,如果没有嵌套,例如,您需要创建仅列出所有可能的汽车缺陷的字典路线/defects
。所以会有名字冲突。
此外,如果没有嵌套,您将如何过滤项目,您将使用嵌套过滤?
defects?car_id=1&repair_id=2&defect_id=3
喜欢这个?这看起来很难看。
有人可以指向一本书或一篇文章,或者给出关于最大嵌套级别和之前列出的问题的答案。 谢谢。
答案 0 :(得分:0)
以下是关键点:REST不会关注您用于标识符的拼写。
也就是说,REST认为每个URI都同样好。
/cars/{car_id}/repairs/{repair_id}/defects
/08617423-cc74-4967-9a67-49e4171f01b7
就客户端而言,标识符是不透明的;将信息编码到URI中由服务器自行决定是否专用。
除此之外,标识符拼写约定是有效的代码风格约定;使用与当地风格一致的拼写。
从客户端的角度来看,标识符不描述资源的语义;这是超媒体表现的工作。