Rest API 设计与资源和深度资源答案

【问题标题】：Rest API design with resource and deep resourceRest API 设计与资源和深度资源
【发布时间】：2021-12-09 04:35:33
【问题描述】：

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

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

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

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

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

/accounts/{id}/服务

/accounts/{id}/checks

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

为将来添加的每个深层资源相应地处理后端逻辑。

欣赏您的见解。

【问题讨论】：

【解决方案1】：

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

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

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

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

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

【讨论】：