RESTful 风格的系统六个特征¶

服务端与客户端分离（Client-Server）:

分离开用户界面和数据存储所关注的逻辑，有助于提高用户界面跨平台的可移植性。

不分离的情况如: 原始的jsp, php，服务代码与html混在一起
风水轮流转:
由于前端的日渐强势，开始出现前端代码反过来驱动服务端进行渲染的 SSR 技术

无状态（Stateless）:

这是 REST 的一条关键原则

REST 希望服务器能不负责维护状态，
每一次从客户端发送的请求中，应该包括所有必要的上下文信息，会话信息也由客户端保存维护，
服务器端依据客户端传递的状态信息来进行业务处理，并且驱动整个应用的状态变迁。

服务端无状态可以在分布式环境中获得很高价值的好处。

注: 越复杂、越大型的系统越难达到此标准。
  大型系统的上下文状态数量太大，可能客户端在发送请求时，无法全部囊括系统里所有必要的上下文信息。

可缓存（Cacheability）:

无状态服务，虽然提升了系统的可见性、可靠性和可伸缩性，但也降低了系统的网络性。
  即: 无状态的服务则可能会需要多个请求，或者在请求中带有冗余的信息。
为缓解这矛盾，REST 希望软件系统能像万维网一样，客户端和中间的通讯传递者（代理）可将部分服务端的应答缓存

运作良好的缓存机制可以减少客户端、服务器之间的交互，甚至有些场景中可以完全避免交互，这就进一步提高了性能

分层系统（Layered System）:

客户端一般不需要知道是否直接连接到了最终的服务器，或者是连接到路径上的中间服务器。
中间服务器可以通过负载均衡和共享缓存的机制，提高系统的可扩展性，这样也便于缓存、伸缩和安全策略的部署。

统一接口（Uniform Interface）:

REST 希望开发者面向资源编程，
  希望软件系统设计的重点放在抽象系统该有哪些资源上，而不是抽象系统该有哪些行为（服务）上。

统一接口也是 REST 最容易陷入争论的地方，
  基于网络的软件系统，到底是面向资源更好，还是面向服务更合适，
  这件事情在很长的时间里恐怕都不会有个定论，也许永远都没有。
但是，有一个已经基本清晰的结论是：面向资源编程的抽象程度通常更高。

坏处是往往距离人类的思维方式更远
好处是往往通用程度会更好。

举例:
  后台管理上的登录、注销功能
说明:
  面向服务的概念: 登录=>login、注销=>logout
  面向资源的概念:
      设定一个Session 资源
      登录=> PUT Session
      注销=> DELETE Session

要在架构设计中合理恰当地利用统一接口，Fielding 给出了三个建议：
  第一，系统要能做到每次请求中都包含资源的 ID，所有操作均通过资源 ID 来进行；
  第二，每个资源都应该是自描述的消息；
  第三，通过「超文本」来驱动应用状态的转移。

按需代码（Code-On-Demand）:

被 Fielding 列为了一条可选原则
  原因其实并非是它特别难以达到，更多是出于必要性和性价比的实际考虑。

按需代码是指任何按照客户端（如浏览器）的请求，将可执行的软件程序从服务器发送到客户端的技术。

例子:
以前的 Java Applet 技术、今天的 WebAssembly 等都属于典型的按需代码，
蕴含着具体执行逻辑的代码存放在了服务端，
只有当客户端请求了某个 Java Applet 之后，
代码才会被传输并在客户端机器中运行，结束后通常也会随即在客户端中被销毁掉。