两者都不是RESTful的。在RESTful应用程序中,URI的语义应该与客户端无关。
REST是基于Web本身的架构风格。想一想,当你访问Stack Overflow时,你唯一关心的URI是 stackoverflow.com
。一旦你登录成功,你会被重定向到你的主页,此时你的主页的URI是无关紧要的。现在我在我的菜单栏上有一个链接,指向我的主页,你也有一个相同的链接,指向你的主页,在我们点击它时,我们不关心URI是什么,对吧?在我们的主页上,我们看到问题和答案,我们也不关心它们的URIs,只关心它们的标题和描述。
现在,让我们反过来想。REST是Web的架构风格,如果Web就像你认为的REST那样,当你加入stackoverflow.com
时,你不会得到一个好的链接,而只会得到一个文本,上面写着“你的ID是131809,请将URI模式/users/(id)替换为这个数字,将其粘贴到地址栏中,然后你就可以进入你的主页了”,你会想,“为什么这些白痴不给个链接呢?”
听起来很荒谬,但这就是大多数人认为REST是什么。 REST API必须受到超文本驱动。
这意味着,与其担心用户的订单应该在/customer/(customer_id)/orders
,还是只在/customer/orders
,甚至只在/orders
,并依赖于他的凭据,迫使客户端了解所有这些URI模式,你应该在API入口点给他一个根文档,考虑到他的凭据,并以标准的标题和描述给出URIs,就像任何网站在你登录时所做的那样!
因此,假设你使用JSON,你的API是myapi.com
。那应该是客户端知道的唯一URI。当他用正确的授权头部发送GET
请求到该根文档时,他应该得到一个JSON文档,如下所示:
{"orders": "http://myapi.com/customer/123456/orders"}
显然,他不需要知道“orders”价值是多少,只需要知道它是一个有效的URI,可以引导他到另一个资源,包含他的订单集合。该URI可以是任何东西,语义并不重要。它可能是你朋友建议的:
{"orders": "http://myapi.com/orders"}
或者其他任何可以随时更改的内容:
{"orders": "http://myapi.com/this/is/a/meaningless/uri"}
当然,你应该付出一些努力来获得清晰而有意义的URI,但这并不会使你的API更或者更少RESTful。在这个问题上的关键是,让你的客户端如何获取URI,如果你的客户端在文档中阅读URI模式而不是在其他资源中获得链接,则你的API就不是RESTful的。简单来说,这就是区别。