属性值可以用作 REST url 中的标识符吗答案

【问题标题】：Can attribute values be used as identifiers in REST urls属性值可以用作 REST url 中的标识符吗
【发布时间】：2021-02-09 10:55:33
【问题描述】：

我有一个具有标识符 id 和属性名称的资源 - 每个资源实例的名称都是唯一的。

为了获取、修补和删除资源，使用名称字段是否符合 REST 和 JSON:API 作为 URL 中的标识符？

例如按名称获取资源，是否符合以下 URL：

GET /resource/{name}

或者以下是使用/更可取的：

GET /resource?name={name}

按名称打补丁或删除，可以一个用：

补丁 /resource/{name}

删除 /resource/{名称}

【问题讨论】：

【解决方案1】：

为了获取、修补和删除资源，使用名称字段作为 URL 中的标识符是否符合 REST 和 JSON:API？

是的。 REST 并不关心您对资源标识符使用什么拼写，只要这些标识符与 RFC 3986 中定义的生产规则一致即可。

这可能意味着您需要编码属性名称 - 例如，用等效的十六进制表示替换一些保留字符。

GET /resource/{name}
PATCH /resource/{name}
DELETE /resource/{name}

没关系

GET /resource?name={name}
PATCH /resource?name={name}
DELETE /resource?name={name}

也不错。这是一种权衡；将信息编码为路径段意味着您可以利用相对引用和点段。在查询部分使用键值对意味着您可以使用 HTML 表单来允许客户端指定名称。

GET /resource?name={name}
DELETE /resource/{name}

从技术上讲，你可以玩混搭，但通用缓存不会知道你很聪明，并且不会在 URI 不同时 invalidate 缓存条目。

这个答案完全忽略了它也应该符合JSON API specification。

这是中肯的评论。

JSON:API specification 没有对 URI 中使用的拼写约定引入任何重大限制。

不过，它确实希望标识符可以使用 application/x-www-form-urlencoded 键值对进行扩展，以支持 sorting、pagination、filtering 等。

（警告：阅读 JSON:API 规范时请小心，因为在 REST 的上下文中，“资源”的使用与 resource 的含义并不一致。）

JSON:API recommendations for URI design 鼓励使用路径段来引用“资源”，就好像它们是单个“参考文档”的单独可寻址 hierarchically organized 元素一样。

此外，建议要求使用特定的分层拼写，使用资源的类型和标识符来计算其 URI

/{type}/{id}

换句话说，GET /resource/{name} 应该返回一个带有type 成员resource 和id 成员name 的application/vnd.api+json 表示。规范应用了此（类型、id）组合必须为unique 的附加约束。

如果 name 只是一个属性，而不是真正的标识符，那么 JSON:API recommends 即您将其视为过滤器

/resource?filter%5Bname%5D=abcde

并且返回的表示将包括一个self 链接关系，它以通常的方式跟踪标识符。

(注意：[]是RFC 3986 gen-delims，因此在查询部分需要十六进制编码。至少有一个JSON:API示例includes a note解释了这一点，但推荐中的过滤示例并没有强调这一点。在实践中? 你可以不编码使用它们——在查询部分使用方括号是一种常见的不符合约定）。

【讨论】：