Question

在发布此问题之前，我阅读了以下书籍和链接，并且由于该问题与最佳实践有关，因此可能会关闭该问题。但是我希望有一些专家的意见。

https://www.restapitutorial.com/resources.html REST-API-设计-规则书其他博客文章和stackoverflow问题。

例如，要获取有关具有id的员工的信息，我们使用uri，如下所示

http://myapp-name.myorganization.com/employees/employeeid/123456

但是以上所有资源告诉我要这样做

http://myapp-name.myorganization.com/employees/123456

类似地，如果我想获取有关ID为12345的员工的信息，我的uri如下所示

http://myapp-name.myorganization.com/countries/country/US/employeeid/12345

相对

http://myapp-name.myorganization.com/countries/US/12345

这是否意味着我的uri不符合标准？

Answer 1

它们只是准则。您无法在Rest文档中涵盖各种业务可能性和必需品。

谈论您的示例

http://myapp-name.myorganization.com/employees/employeeid/123456

和

http://myapp-name.myorganization.com/employees/123456

都是正确的。但可能会更好（更短）。

通常，我更喜欢第二个，并且将第一个用于替代方案。例如，如果我想通过id（找到员工的“默认”方法）或他独特的公司内部代码来查找员工，则我想分别使用：

/employees/123456         # by id
/employees/code/A899123A  # by code

同样，如果我要获取有关ID为12345的员工的信息，我的uri如下 http://myapp-name.myorganization.com/countries/country/US/employeeid/12345

此URL对我来说意味着您试图在美国国家/地区找到ID为12345的员工。但是，如果US术语是在您的API上查找国家/地区的默认方法，则它也可以更短：

 /countries/US/employees/12345

与http://myapp-name.myorganization.com/countries/US/12345
相反

这似乎令人困惑。您是否要查找ID为12345的内容？仅查找URL很难回答。因此，/countries/US/employees/12345更加一致。

如果该想法是在某个国家/地区找到具有某些代码的员工，则URL可以采用相同的模式：/countries/US/employees/code/A899123A

Answer 2

我的uri不符合标准吗？

否，您的URI很好。 REST不在乎您将标识符用作什么拼写，只要它们与RFC 3986一致即可。还有RFC 7320，其中描述了“最佳做法”-但您可能会发现这些最佳做法仍然给您带来很大的自由度。

考虑“变量名”-各种社区对于如何拼写变量名都有自己的约定，但是没有任何标准。

REST中的标识符也是如此-它们是API使用者和客户端实际上都不需要解析的不透明字符串。（例如：您最后一次真正看到您向Google提交搜索时使用的URI是什么？）

如果遵循特定的约定，则某些路由框架将更易于使用，但这纯粹是服务器上的实现细节，客户端不在乎。