REST服务，UI和服务分离

Question

我正在尝试了解RESTful服务。 在我正在观看的本教程中，讲师指出以下内容：

REST服务使UI和服务之间的定义变得非常明确。

• 通常，作者在这里暗示什么？
• 用户界面中使用的服务与用户界面的其余部分相比很容易发现？
• UI的其余部分是CSS，HTML，还是存储在本地应用程序中的某些数据？
• UI和服务之间为什么需要明确区分？

您是否知道现有的示例，我可以看一下以更好地从视觉上理解？

Answer 1

如果没有嵌入上下文的话，就不可能确切地解释较大摘录中的单个句子的含义。 但是我还是去。 我怀疑涉及炒作的因素-无法保证Restful API的设计要比非Restful API更好，因此，实际上无法保证它将更好地实现UI逻辑和业务逻辑之间的分离，都希望看到。

但是，Rest的文档中心主义，对无状态的关注以及对统一API的使用确实有助于在UI（Web应用程序或移动应用程序）和服务器之间创建干净的层。

其他形式的面向服务的体系结构，例如RMI或SOAP，往往更侧重于提供一种访问远程API的方式，就好像它是本地的一样-本质上掩盖了网络负载正在发生的事实。 结果通常是非常细粒度但功能强大的API，该API需要嵌入客户端应用程序中的复杂逻辑（ 业务逻辑）才能正确使用。 这些协议可能非常闲谈，并且网络效率低下，因为很少关注于通过网络传输的数据。

以文档为中心的Restful API倾向于将UI设计器推向编辑这些文档的方向-将UI集中在表示上，并将逻辑留给用户或后端服务。

Rest的统一接口有助于使API专注于处理文档-每种资源的访问方式都相同，几乎没有余地添加可以由客户端以某种方式“解释”的自定义响应代码。 出于这个原因，HTTP是一个构建Restful API的好协议-主要动词是GET，PUT，POST和DELETE。

类似地，Rest的无状态性促使UI着重于其拥有的数据及其应如何处理，而不是向用户提供任何类型的中间转换或缓存层。 除了要向用户提供的文档外，UI所提供的信息也不多-漂亮而又简单。

我猜，您问题的真正核心是“为什么要这样”？ 答案是，它使事情变得简单灵活。 表示逻辑（例如，用户关心的语言，时区或数字格式）不应与业务逻辑（用户过去购买了多少个“ foo”小部件，他们是否真的想要一个“ bar”小部件）混合使用，因为很多购买“ foo”小部件的人也想要“ bar”小部件）。 这两种类型的事物具有非常不同的更改原因，并且不同类型的人擅长使用基础代码。