要使用基于其他标识符的资源来获得剩余API约定是什么?
例如
GET
/resource/{id}
GET
/resource/{guid}
由于这可能被视为重复资源,并且为此设置了路由可能会成为问题,那么遵循其余API准则又有什么选择呢?
也许
/ resources /?guid = {guid}
或
/ resources / guid / {guid}
还是其他?
答案 0 :(得分:2)
您可以同时使用/resource/{id}
和/resource/{guid}
。许多框架支持正则表达式来匹配路径参数值。
REST是一种建筑风格,而不是(请参阅以下说明)的URI设计指南。它不执行任何URI设计,并且完全由您来选择可以更好地标识资源的URI。
您应该牢记的是:对同一实体使用multiple mappings是完全可以的。根据Fielding的论文,每个映射都是资源:
资源是到一组实体的概念映射,而不是在任何特定时间点对应于该映射的实体。
话虽如此,如果您支持DELETE
,请务必提及其工作原理:
DELETE
方法请求原始服务器删除目标资源与其当前功能之间的关联。实际上,此方法类似于UNIX中的rm
命令:它在源服务器的URI映射上表示删除操作,而不是期望删除先前关联的信息。 [...]
注释1: URI语法在RFC 3986中定义。通常,该路径以 hierarchical 形式组织(各段之间用/
分隔),并且可以在查询组件中(从?
开始包含非分层数据)。
注释2: REST体系结构样式在Roy T的chapter 5中进行了描述。Fielding的论文中定义了一组约束,应用程序必须遵循这些约束遵循这样的架构。但是,它并没有说明URI必须是什么样。
注释3: Martin Fowler撰写的popular article的示例解释了伦纳德·理查森(Leonard Richardson)定义的模型<建议> >看起来友好且易于阅读的URI结构。
答案 1 :(得分:1)
我通常不会复制端点。问题是:
为什么一个客户有一个ID,而另一个客户有一个GUID?
什么设计选择可以实现?
我将其保留为单个资源端点:
GET
/resource/{id}
因此,通过其ID访问资源的客户端将使用上述端点。我允许通过guid访问资源的客户将他们所拥有的(guid)交换为他们所需要的(id):
GET
/id/{guid}
以上返回给定资源guid的资源ID。然后,客户端可以使用他们刚收到的ID调用主资源端点:
GET
/resource/{id}
但是最终我会研究为什么有些客户端使用guid而不是id并进行更改,以便所有客户端都以相同的方式访问API。