REST 最佳实践 - 用于填充下拉列表的简化实体列表
REST Best Practices - List of simplified entities to populate dropdown
我们有一个 REST API，其中我们有以下规则：当为“列表实体”用例返回实体列表时，我们执行“GET /entities”，返回所需的字段。
然而，在许多情况下，我们需要实体的简化版本列表（id 和描述），例如填充下拉菜单。在这种情况下是否有“最佳实践”？
我应该使用带有参数的相同“GET /entities”还是应该将这个简化列表视为新资源？在那种情况下（新资源），该资源将与原始列表处于同一级别 (GET /entities-for-dropdown) 或者它可能是子资源 (GET /entities/dropdown)？还有其他（更好的）解决方案吗？
您还有其他选择，由您决定它们是否更好。以下是一些随机顺序：
我将在下面详细说明这些。
有限的列表结果，广泛的细节
这是最常用的 - 用于源代码检查各种 API/CLI 的 AWS CLI
GET /entities 将 return 典型的内容，例如 ID、名称、简短描述以及您在简短概述中通常期望的所有内容。
GET /entities/id，详细视图检索实体的所有相关信息。
公开所有列表
通常用于细节不是很广泛的场景。
使用OData
等查询语言
标题说明了一切。它允许 select 和 expand，例如：
http://host/service/Products?$select=Rating,ReleaseDate（参见MSDN）
有人看到有人在做自己的自定义实现。
使用GraphQL或类似的查询语言来快速定制您的端点
这将为您提供根据用例更改端点的灵活性，而无需更改基础 API（太多）。它类似于您创建自定义端点的场景。
实施根据要求量身定制的自定义端点
易于实施，但如果经常发生更改，则更难维护和更改。
我们有一个 REST API，其中我们有以下规则：当为“列表实体”用例返回实体列表时，我们执行“GET /entities”，返回所需的字段。
然而，在许多情况下，我们需要实体的简化版本列表（id 和描述），例如填充下拉菜单。在这种情况下是否有“最佳实践”？
我应该使用带有参数的相同“GET /entities”还是应该将这个简化列表视为新资源？在那种情况下（新资源），该资源将与原始列表处于同一级别 (GET /entities-for-dropdown) 或者它可能是子资源 (GET /entities/dropdown)？还有其他（更好的）解决方案吗？
您还有其他选择，由您决定它们是否更好。以下是一些随机顺序：
我将在下面详细说明这些。
有限的列表结果，广泛的细节
这是最常用的 - 用于源代码检查各种 API/CLI 的 AWS CLI
GET /entities 将 return 典型的内容，例如 ID、名称、简短描述以及您在简短概述中通常期望的所有内容。
GET /entities/id，详细视图检索实体的所有相关信息。
公开所有列表
通常用于细节不是很广泛的场景。
使用OData
等查询语言标题说明了一切。它允许 select 和 expand，例如：
http://host/service/Products?$select=Rating,ReleaseDate（参见MSDN）
有人看到有人在做自己的自定义实现。
使用GraphQL或类似的查询语言来快速定制您的端点
这将为您提供根据用例更改端点的灵活性，而无需更改基础 API（太多）。它类似于您创建自定义端点的场景。
实施根据要求量身定制的自定义端点
易于实施，但如果经常发生更改，则更难维护和更改。