属性值可以用作 REST url 中的标识符吗
Can attribute values be used as identifiers in REST urls
我有一个具有标识符 ID 和属性名称的资源 - 每个资源实例的名称都是唯一的。
为了获取、修补和删除资源,使用名称字段是否符合 REST 和 JSON:API
作为 URL?
中的标识符
例如要按名称获取资源,是否符合以下 URL:
获取/资源/{名称}
或者是否使用/更可取:
GET /resource?name={name}
按名称修补或删除,可以使用:
补丁/资源/{名称}
删除/资源/{名称}
In order to get, patch and delete the resource, is it REST and JSON:API compliant to use the name field as the identifier in the URL?
是的。 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}
从技术上讲,您可以玩 mix-and-match,但通用缓存不会知道您的聪明,并且当 URI 不同时不会 invalidate 缓存条目。
This answer fully ignores that it should be also compliant with JSON API specification.
这是公平的评论。
JSON:API specification 没有对 URI 中使用的拼写约定引入任何重要限制。
但是,它确实希望可以使用 application/x-www-form-urlencoded 键值对扩展标识符以支持 sorting, pagination, filtering 等等。
(警告:阅读 JSON:API 规范时请小心,因为“资源”的使用与 resource in the context of REST 的含义不太吻合。)
单个“参考文档”的 JSON:API recommendations for URI design encourage the use of path segments for referencing "resources" as though they were individually addressable hierarchically organized 个元素。
此外,建议要求使用特定的分层拼写,使用资源的类型和标识符来计算其 URI
/{type}/{id}
换句话说,GET /resource/{name}
应该 return 具有 type
成员 resource
和 id
成员的 application/vnd.api+json
表示 name
。该规范应用了附加约束,即此 (type, id) 组合必须是 unique.
如果 name
只是一个 属性,而不是真正的标识符,那么 JSON:API recommends 你把它当作一个过滤器
/resource?filter%5Bname%5D=abcde
并且表示 returned 将包含一个 self link 关系,该关系以通常的方式跟踪标识符。
(注意:[] 是 RFC 3986 gen-delims, and therefore require hex encoding in the query part. At least one of the JSON:API examples includes a note 解释这一点,但推荐中的过滤示例并未强调这一点。在实践中?您可能会在未编码的情况下使用它们——在查询中使用方括号部分是一个常见的 non-compliant 约定)。
我有一个具有标识符 ID 和属性名称的资源 - 每个资源实例的名称都是唯一的。
为了获取、修补和删除资源,使用名称字段是否符合 REST 和 JSON:API 作为 URL?
中的标识符例如要按名称获取资源,是否符合以下 URL:
获取/资源/{名称}
或者是否使用/更可取:
GET /resource?name={name}
按名称修补或删除,可以使用:
补丁/资源/{名称}
删除/资源/{名称}
In order to get, patch and delete the resource, is it REST and JSON:API compliant to use the name field as the identifier in the URL?
是的。 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}
从技术上讲,您可以玩 mix-and-match,但通用缓存不会知道您的聪明,并且当 URI 不同时不会 invalidate 缓存条目。
This answer fully ignores that it should be also compliant with JSON API specification.
这是公平的评论。
JSON:API specification 没有对 URI 中使用的拼写约定引入任何重要限制。
但是,它确实希望可以使用 application/x-www-form-urlencoded 键值对扩展标识符以支持 sorting, pagination, filtering 等等。
(警告:阅读 JSON:API 规范时请小心,因为“资源”的使用与 resource in the context of REST 的含义不太吻合。)
单个“参考文档”的 JSON:API recommendations for URI design encourage the use of path segments for referencing "resources" as though they were individually addressable hierarchically organized 个元素。
此外,建议要求使用特定的分层拼写,使用资源的类型和标识符来计算其 URI
/{type}/{id}
换句话说,GET /resource/{name}
应该 return 具有 type
成员 resource
和 id
成员的 application/vnd.api+json
表示 name
。该规范应用了附加约束,即此 (type, id) 组合必须是 unique.
如果 name
只是一个 属性,而不是真正的标识符,那么 JSON:API recommends 你把它当作一个过滤器
/resource?filter%5Bname%5D=abcde
并且表示 returned 将包含一个 self link 关系,该关系以通常的方式跟踪标识符。
(注意:[] 是 RFC 3986 gen-delims, and therefore require hex encoding in the query part. At least one of the JSON:API examples includes a note 解释这一点,但推荐中的过滤示例并未强调这一点。在实践中?您可能会在未编码的情况下使用它们——在查询中使用方括号部分是一个常见的 non-compliant 约定)。