Question

要使用基于其他标识符的资源来获得剩余API约定是什么？

例如

GET
/resource/{id}

GET
/resource/{guid}

由于这可能被视为重复资源，并且为此设置了路由可能会成为问题，那么遵循其余API准则又有什么选择呢？

也许

/ resources /？guid = {guid}

或

/ resources / guid / {guid}

还是其他？

Answer 1

简短答案

您可以同时使用/resource/{id}和/resource/{guid}。许多框架支持正则表达式来匹配路径参数值。

长答案

REST是一种建筑风格，而不是^{（请参阅以下说明）}的URI设计指南。它不执行任何URI设计，并且完全由您来选择可以更好地标识资源的URI。

您应该牢记的是：对同一实体使用multiple mappings是完全可以的。根据Fielding的论文，每个映射都是资源：

资源是到一组实体的概念映射，而不是在任何特定时间点对应于该映射的实体。

话虽如此，如果您支持DELETE，请务必提及其工作原理：

4.3.5. 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结构。}

Answer 2

我通常不会复制端点。问题是：

为什么一个客户有一个ID，而另一个客户有一个GUID？

什么设计选择可以实现？

我将其保留为单个资源端点：

GET
/resource/{id}

因此，通过其ID访问资源的客户端将使用上述端点。我允许通过guid访问资源的客户将他们所拥有的（guid）交换为他们所需要的（id）：

GET
/id/{guid}

以上返回给定资源guid的资源ID。然后，客户端可以使用他们刚收到的ID调用主资源端点：

GET
/resource/{id}

但是最终我会研究为什么有些客户端使用guid而不是id并进行更改，以便所有客户端都以相同的方式访问API。