在发布此问题之前,我阅读了以下书籍和链接,因为这个问题是关于最佳做法的,所以这个问题可能会被关闭。但是我期待一些专家意见。
来自o'reilly其他博客文章和stackoverflow问题的qazxsw poi REST-API-Design-Rulebook书。
例如,要获取有关id的员工的信息,我们使用https://www.restapitutorial.com/resources.html,如下所示
uri
但以上所有资源都告诉我这样做
http://myapp-name.myorganization.com/employees/employeeid/123456
同样,如果我想获取有关ID为12345的员工的信息,我的uri如下所示
http://myapp-name.myorganization.com/employees/123456
而不是
http://myapp-name.myorganization.com/countries/country/US/employeeid/12345
这是否意味着我的uri不标准?
它们只是指导方针。您不能在Rest文档中涵盖您的业务和必需品的各种可能性。
谈到你的例子,
http://myapp-name.myorganization.com/countries/US/12345
和
http://myapp-name.myorganization.com/employees/employeeid/123456
都是正确的。但可能更好(更短)。
通常我更喜欢第二个,并使用第一个替代。例如,如果我想通过id(找到员工的“默认”方法)或他独特的内部公司代码找到员工,我更愿意分别使用:
http://myapp-name.myorganization.com/employees/123456
同样,如果我想获取有关ID为12345的员工的信息,我的uri如下
/employees/123456 # by id /employees/code/A899123A # by code
此URL意味着您尝试在美国国家/地区找到ID为12345的员工。但如果http://myapp-name.myorganization.com/countries/country/US/employeeid/12345术语是在API上查找国家/地区的默认方法,那么也可能更短:
US
而不是
/countries/US/employees/12345
这个似乎很混乱。你想找到id 12345的东西吗?仅查找URL很难回答。所以,http://myapp-name.myorganization.com/countries/US/12345更加一致。
如果想法是在某个国家/地区找到具有某些代码的员工,则该URL可以遵循相同的模式:/countries/US/employees/12345
这是我的uri不标准吗?
不,你的URI很好。 REST不关心您用于标识符的拼写,只要它们与/countries/US/employees/code/A899123A
一致即可。还有RFC 3986,它描述了“最佳实践” - 但你可能会发现那些最佳实践仍然给你带来很多自由。
想想“变量名称” - 各种社区对变量名称的拼写方式都有自己的约定,但没有任何标准。
REST中的标识符也是如此 - 它们是API消费者和客户端实际上都不需要解析的不透明字符串。 (例如:您最后一次查看向Google提交搜索时使用的URI的时间?)
如果您遵守特定约定,某些路由框架将更容易使用,但这纯粹是服务器上的实现细节,客户端并不关心。