只读派生 REST 资源？答案

【问题标题】：A read-only derived REST resource?只读派生 REST 资源？
【发布时间】：2017-07-11 05:55:23
【问题描述】：

我正在创建一个新服务，我需要在其中支持对两个实体进行标记。我可以将/tags 创建为仅支持以下调用的顶级 REST 资源吗：

GET    /tags

GET    /tags/{tagName}

要应用标签，我们使用以下调用：

PATCH    /entity1/{entity_1_Name}

PATCH    /entity2/{entity_2_Name}

因此，无论何时将标签应用于实体，随后对GET /tags 的调用都会显示该标签。我打算这样做，因为这不需要我将标签独立存储在我的数据存储中。

这是个好主意吗？

【问题讨论】：

标签： rest api restful-url

【解决方案1】：

我可以将 /tags 创建为顶级 REST 资源吗

是的，你可以。如果tag 是一个独立实体并且api 响应将仅包含tag_name 和其他与标签相关的信息，这听起来很有意义。如果您的 api 有数据库或 web.config 或者它处理硬编码的值列表，这并不重要。无论如何，您的 API 接口隐藏这个事实，用户永远不会知道实现的细节。可以有一个只读实体。

每当一个标签被应用到一个实体上，随后对 GET /tags 的调用都会显示该标签

我希望您的 GET /entity2/{entity_2_Name} 资源模型将有一个 tags 字段：

class Entity2
{
    string entity_name;
    ...
    string[] tags
}

作为替代方法，您可以通过两次调用获取所有数据：

GET /entity2/{entity_2_Name} //响应中没有标签数组

GET /entity2/{entity_2_Name}/tags

资源/entity2/{entity_2_Name}/tags 应该返回分配给这个具体entity2 实例的标签

【讨论】：

在顶层设置 /tags 是个好主意，它返回系统中创建的所有标签。响应将是一个 Tag 对象的列表，其中包含它们的名称以及用于该标记的所有可能的标记值。
@aman 是的，它适合休息。如果将来标签的数量会增加并且普通列表会变得不方便使用，您可能希望使用搜索扩展此调用： GET /tags?query=sometag