时间戳

首页 > 解决方案 > Rest API 设计与资源和深度资源

api - Rest API 设计与资源和深度资源

问题描述

在设计将具有资源和深度资源（/resource/{id}/deepResource）的 API 时，当有许多动态 deepResources 时，将 deepResource 作为资源路径中的参数是否是一个好的设计？

例如：在主资源的一部分下创建新资源的post请求

POST: /accounts/{id}/{section}

{section} 可以是账户下的任何深度资源，如“评论”、“服务请求”、“支票簿请求”等。

这个想法是 {section} 可以随着应用程序的增长而增长。因此，不要为每个深层资源（如 /accounts/{id}/comment）设置多个端点

/accounts/{id}/服务

/accounts/{id}/支票

/accounts/{id}/{section} 怎么样？

对于将来添加的每个深层资源，都会相应地处理后端的逻辑。

欣赏您的见解。

标签： apirestdesign-patternsapi-design

解决方案

/accounts/{id}/{section} 怎么样？

如果这对您有用，请继续。

REST不关心你如何实现你的后端。

REST 也不关心您如何构建资源标识符。将请求目标复制到 HTTP 请求中后，无论您使用带有一个参数、两个参数还是根本没有参数的 URI 模板，都不再重要。

在某些 API 描述语言（swagger/openapi、jsonapi 等）中，您可能会发现很难描述不同部分的细微差别，尤其是在“评论”、“服务”、“检查”具有不同内容类型、不同架构等。

推荐阅读