两者都不是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的。简单来说，这就是区别。
