在REST中，URI对客户端应该是不透明的。 但是当你为你的应用程序构建基于javascript的交互式web客户端时，你实际上有两个客户端！一个用于与服务器交互，另一个用于用户（实际GUI）。当然你会想要友好的URI，足以回答“我现在在哪里？”的问题。
当服务器只响应HTML时更容易，因此人们只需点击链接而不关心结构。服务器提供URI，服务器接收URI。
桌面客户端更容易。同样的员工。只需一个按钮“显示资源”，用户不关心URI是什么。
浏览器客户端很复杂。有地址栏。这导致Web客户端的低级部分依赖于服务器的URI结构。哪个不是RESTful。
看起来应用程序的前端和后端之间的空间对于REST来说太紧了。
这是否意味着REST不适合基于反应式交互式js的浏览器客户端？
答案 0 :(得分：0)
我觉得你有点困惑......
首先，您最初的假设是有缺陷的。 URI不透明度并不意味着URI必须是神秘的。它只意味着客户端不应该依赖URI语义进行交互。友好的URI不仅是允许的，我们鼓励它们与您谈论的完全相同的原因：开发人员更容易知道发生了什么。
Roy Fielding made that clear几年前在REST邮件列表中，但这似乎是一个不容易消失的神话：
REST不要求URI是不透明的。唯一的地方 在我的论文中出现不透明的词是我抱怨的地方 饼干不透明。实际上，RESTful应用程序根本就是 鼓励使用人类有意义的分层标识符 为了最大限度地利用信息的偶然使用 原始申请预计。
其次，当服务器只回复HTML时，你会说它更容易，所以人们可以只关注链接而不关心结构。好吧，这正是REST应该做的事情。 REST仅仅是对Web本身的架构风格的更正式和抽象的定义。做一些关于REST和HATEOAS的研究。
最后，回答你的问题，REST是否是一个不错的选择并不是由客户端实现细节决定的。您可以拥有基于js的客户端，没有问题，但是这样做的必要性并不足以让人过分担心REST的正确性。如果您拥有具有长期集成，可维护性和发展目标的项目，REST是一个不错的选择。如果你需要快速的东西，不会发生很大的变化，或者不能与很多不同的客户和服务集成，那就不用担心REST。