我正在尝试了解RESTful服务。在本教程中，我正在观看，教师说明如下：
REST服务可以在UI与什么是服务之间保持非常明确的定义。
你知道一个现有的例子，我可以看一看，以便更好地在视觉上理解吗？
答案 0 :(得分：4)
如果没有嵌入的上下文，可能无法准确解释较大提取中的单个句子是什么意思。但无论如何我还要去。我怀疑是否存在涉及炒作的因素 - 并不能保证Restful API的设计比非宁静的API更好，因此无法保证它能更好地实施分离在UI逻辑和业务逻辑之间，我们都喜欢看。
然而，Rest的文档中心主义，它对无状态的关注，以及它使用统一的API 做有助于在UI（webapp或移动应用程序）和UI之间创建一个干净的层。服务器
其他形式的面向服务的体系结构，例如RMI或SOAP，往往更侧重于提供一种访问远程API 的方法，好像它是本地的 - 实质上隐藏了这样一个事实：负载网络的东西正在发生这样的事情。结果通常是一个非常细粒度但功能非常强大的API，它需要在客户端应用程序中嵌入复杂的逻辑（业务逻辑）才能正常使用。这些协议可能非常繁琐且网络效率低，因为很少关注通过网络传输的数据。
以文档为中心的Restful API倾向于推动UI设计人员编辑这些文档 - 将UI集中在演示文稿上，并将逻辑留给用户或后端服务。
Rest的统一界面有助于将API集中在处理文档上 - 每个资源都以相同的方式访问，添加自定义响应代码的余地很小，可以通过这些代码解释＆＃39;在某种程度上由客户。由于这个原因，HTTP是构建Restful API的好协议 - 主要动词是GET，PUT，POST和DELETE。
类似地，Rest的无状态推动UI专注于它拥有的数据以及它应该如何，而不是向用户提供任何类型的中间转换或缓存层。用户界面没有比向用户呈现的文档更多的信息 - 简单明了。
我猜你问题的真正核心是＆＃34;为什么它应该像那样＆＃34;？答案就是它保持简单和灵活。演示逻辑（例如，用户关心的语言或时区或数字格式）不应与业务逻辑混淆（用户过去购买了多少“小部件”，他们真的想要一个立即使用“小工具”小部件，因为很多购买“小工具”小部件的人也想要“小工具”。这两类事物有不同的改变理由和不同类型的擅长使用底层代码的人。