问使用非唯一ID设计REST资源，但使用唯一的复合ID

EN

对于如何在REST中构建URL没有严格的规则，只有常识和最佳实践(例如，这里是一这样的指南，在很多方面都是如此)。从REST的角度来看，URL的外观并不重要。像/da39a3ee5e6b4b0d3255b这样的东西只要标识资源就可以了。

在您的示例中，整个URL是任何特定点上的资源标识符(无论是实体集合还是单个实体的资源标识符)。因此，如果您可以正确地构建URL，这样就不会有可能导致一个标识符指向更多资源的重叠，那么无论您如何构建URL以及它们包含什么名称，您都应该没有问题。

尽管如此，如果您决定使用名称(您没有确切地提到这些名称所包含的内容，所以我将假设一些纯文本)，但也存在一些问题。就像我说过的，REST不关心URL。我们为用户构建这样的用户友好URL。人们使用。机器不在乎。因此，如果您想要构建具有名称而不是in的URL，请将人员视为目标受众。例如，我的头顶：

• 当人们在不同的地方看到同一个孩子的名字时，他们会感到困惑吗？
• 这些名称是根据某些规则或免费书写创建的吗？如果有人拼错了一个名字，就会用这个名字创建一个URL。他们找出了他们的错误，然后修正了它。现在，您将获得另一个URL，其名称正确，指向相同的资源。你怎么处理这件事？在服务器中重写规则？如何使缓存无效？等。
• 国际化？如果人们想要翻译，你可以用N种不同的语言获得相同的名字。然后会发生什么呢？
• 人们能引用子实体并像独立的实体那样处理它们吗？基本上，你在你的帖子里也说过，现在人们需要考虑一个实体的名字，并且总是和他们的父母配对。
• 编码？这些名字到底是什么？例如，你能在UTF-8和ASCII之间把它们搞砸吗？
• 小写名字还是大写名字？它们是不同的名字还是相同的名字？
• 等。

出于这样的原因，这些人通常喜欢在那里贴一个身份证，然后就到此为止。有时他们甚至使用:ID-:Name (即ID、破折号、名称)或:ID/:Name (即ID、斜杠、名称)。ID由应用程序使用，而名称在那里是为了方便人们，而应用程序的实际执行/路由引擎忽略了ID。作为一个例子，查看这个实际的帖子并比较这两个URL：

使用非唯一ID设计REST资源，但使用唯一的复合ID

使用非唯一ID设计REST资源，但使用唯一的复合ID

这个应用程序查看帖子的ID，它是为人和搜索引擎优化之后的。

最后，这个问题没有明确的答案。就像我说的，只是常识和最佳实践。所以，运用常识，阅读一些最佳实践。我个人对此的回答是，由于我上面提到的问题，我尽量避免使用姓名。你可以把名字弄得乱七八糟，但用(通常是数字的)ID就不那么糟了。您的API将更容易使用ID而不是名称来发展。