Question

简单的问题我无法找到答案..

如果我有一个REST Web服务，并且我的设计没有使用url参数，我如何指定两个不同的键来返回相同的资源？

实施例我想（并且已经实施）

/Person/{ID}

按预期返回一个人。

现在我也想要

/Person/{Name}

按名称返回一个人。

这是正确的RESTful格式吗？或者它是这样的：

/Person/Name/{Name}

Answer 1

您应该只使用一个URI来引用单个资源。拥有多个URI只会造成混淆。在您的示例中，由于两个人具有相同的名称而引起混淆。他们指的是哪个人力资源？

也就是说，您可以将多个URI引用到单个资源，但对于“真实”URI以外的任何其他内容，您只需使用状态代码301 - Moved Permanently将客户端重定向到正确的位置。

就个人而言，我永远不会实现多ID方案或重定向来支持它。选择一个识别方案并坚持下去。您的API用户会感谢您。

您真正需要构建的是查询API，因此请关注如何实现类似/personFinder资源的方法，该资源可以将名称作为参数并返回可能多个匹配的/person/{ID} URI回应。

Answer 2

我认为从技术上讲，你可以让两个URI指向同一个资源（也许其中一个作为规范资源），但我认为你不希望从实现的角度来看这个。如果ID和名称之间存在重叠怎么办？

确实看起来确实是使用查询参数的好地方，但如果你坚持不这样做，也许你可以做到

person/{ID}

和

personByName/{Name}

Answer 3

我通常同意this answer的观点，为清楚和一致起见，最好避免多个ID指向同一实体。

但是，有时这种情况自然而然地出现。我与之合作的一个例子是波兰公司，可以通过其税号（'NIP'编号）或其国家商业登记号（'KRS'编号）进行识别。

在这种情况下，我认为应该首先将辅助ID作为标准添加到搜索端点。这样，用户将能够在辅助ID和主要ID之间“翻译”。

但是，如果用户仍然坚持能够通过辅助ID直接检索实体（如我们所经历的那样），则另一种可能性是提供文档中未描述的“秘密” URL，从而执行这样的操作。可以将其提供给那些努力要求它的用户，如果他们决定使用它，那么潜在的歧义和困惑就在他们身上，而不是每个阅读文档的人。

就API维护者的歧义和困惑而言，我认为可以通过使用辅助函数在每个相关API端点的开头立即检测并将辅助ID转换为主要ID的方式将其保持在最小程度。

为秘密URL选择哪种方案显然比正常情况要重要得多。