什么是基于不同标识符获取资源的其他API约定？
例如
GET
/resource/{id}
GET
/resource/{guid}
由于这可以被视为一个重复的资源，并且为此设置路径可能是一个问题，那么什么是替代方案，那么将遵循其他API准则？
也许
/资源/？GUID = {GUID}
要么
/资源/ GUID / {GUID}
或者是其他东西？
我通常不会复制端点。问题是：
为什么一个客户有id而另一个有guid？
什么设计选择允许这种情况发生？
我会将其作为单个资源端点保留：
GET
/resource/{id}
因此，通过其ID访问资源的客户端将使用上述端点。我允许通过他们的guid访问资源的客户交换他们所拥有的东西（guid）以满足他们的需要（id）：
GET
/id/{guid}
以上内容返回给定资源guid的资源ID。然后，客户端可以使用刚收到的id调用主资源端点：
GET
/resource/{id}
但最终我会研究为什么有些客户使用guid而不是id并更改它，以便所有客户端以相同的方式访问API。
你可以使用/resource/{id}和/resource/{guid}。许多框架支持用于匹配路径参数值的正则表达式。
REST是一种架构风格，而不是设计URI的手册（参见下面的注释）。它不强制执行任何URI设计，完全取决于您选择更好地识别您的资源的URI。
你应该记住的是：将multiple mappings用于同一个实体是完全没问题的。根据菲尔丁的论文，每个映射都是一种资源：
资源是到一组实体的概念映射，而不是与任何特定时间点的映射相对应的实体。
话虽如此，如果你支持DELETE，重要的是要提到它应该如何工作：
DELETE方法请求源服务器删除目标资源与其当前功能之间的关联。实际上，此方法类似于UNIX中的rm命令：它表示对源服务器的URI映射执行删除操作，而不是期望删除先前关联的信息。 [...]
注1：URI语法在RFC 3986中定义。作为一般规则，路径以分层形式组织（由/分隔的段）并且可以在查询组件中包含非分层数据（从?开始）。
注2：REST架构风格在Roy T. Fielding的论文的chapter 5中描述，它定义了一组约束，这些约束必须遵循这种架构所遵循的应用程序。但它没有说明URI必须是什么样的。
注3：由Martin Fowler编写的popular article的例子解释了由Leonard Richardson定义的模型，这表明URI结构看起来很友好且易于阅读。