REST风格的API：如何组织嵌套的资源

  • Z时代
  • 2024-01-10
  • 分类：问答

我有关于如何组织API路由结构的问题。阅读了许多关于构建RESTful API的书籍，但无法找到答案。每本书都讲述简单的CRUD操作，并在一个层次上嵌套资源。 Like /users和/users/1/posts。没有问题。REST风格的API：如何组织嵌套的资源

例：

但让我们来看看更加困难现实生活中的例子：

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

喜欢这个？这看起来很丑。

请有人指向一本书或文章，或者给出有关最大嵌套级别和以前列出的问题的答案。 谢谢。

回答：

这里的关键点：REST不护理你用什么拼写标识符。

也就是说，REST认为每个这些URI都是同样好的。

/cars/{car_id}/repairs/{repair_id}/defects 
/08617423-cc74-4967-9a67-49e4171f01b7

至于客户而言，所述标识符是不透明的;将信息编码到URI中是由服务器自行决定完成的，以供它自己使用。

除此之外，标识符拼写约定是有效的代码风格约定;使用与当地风格一致的拼写。

从客户端的角度来看，标识符而不是描述资源的语义;这是超媒体表示的工作。

以上是 REST风格的API：如何组织嵌套的资源 的全部内容， 来源链接： utcz.com/qa/266401.html

回到顶部