是否应在ID或名称字段上选择REST API？ [关闭]

Question

我正在设计REST API并尝试确定返回单个资源的更正确方法：

/resource/{id}

要么

/resource/{name}

ID将是不可变的，所以我认为选择它会更好，但名字会更友好。什么是最佳做法？我已经看到两者都在“野外”之前使用过。

Answer 1

基本上，REST建立在唯一ID之上，因此：

GET    /resources/{id}/

应该使用。但是，没有什么可以阻止您使name字段唯一（现在它表现为普通旧ID）并在此唯一ID之上构建REST。

如果这不是您所需要的并且name不能独特，那么另一种选择是通过name实现过滤：

GET    /resources?name=<SOME_NAME>

它也应该是resources（复数），因为它表明在引擎盖下有一个集合。

Answer 2

是否使用名称取决于您的业务案例。

“名字”总是独一无二的吗？或者应用程序是否会处理不止一次？

'漂亮'的网址很重要吗？在我工作的大多数应用程序中，查询使用从未向最终用户公开的唯一ID，因为它们没有任何商业意义。它们实际上是代理主键。

Answer 3

/resource/{id}在技术上更正确，但如果是我，我会允许两者。假设names不能包含唯一的数字，并且ids只能是数字，您可以轻松地检测出哪些是被提供的并且允许使用它们。 ;）

Answer 4

这是一个很好的问题..它取决于商业案例，如果api通过像docker这样的cli使用，那么你可能想要使用类似用户友好的ID，但是一旦它成为URL的一部分，就会有像ASCII这样的限制（以避免url编码）或丢失可读性）仅限char和一些定义的长度，如128个字符等。