表现层状态转换架构

表现层状态转换 (REST) 架构

应用在实现时，按逻辑上将客户端与服务端分离开来，使得任何一个客户端实例都可以向同一服务器发出请求。依照扮演角色的不同，客户端与服务端的特征区别如下：

主从式架构客户端与服务端分离的特性，改善了应用跨平台的可携性，同时借由服务端组件的简化，大幅地改善整体架构的缩放性。进而使得个别服务端组件得以独立地开发迭代，支持整体架构应付多样化的运维需求。

客户端与服务端间的信息请求响应关系上，要注意服务端不负责记录请求方的用户状态。也就是每一个请求都包含了该服务逻辑所需的完整讯息。因此，通信的会话状态 (Session State) 要由客户端来负责维护。

基于资源所设计的 REST 架构，其资源可自我定义宣告，决定是否快取该请求响应的内容，并且在通信的过程中被缓存。进而改善网络效率，并且提高系统的可伸展性。这个缓存的机制，可在客户端上实现，也可以部署在服务端，甚者多半是采取两者并进的方式。

“一旦开发者熟悉系统中某个特定的应用程式接口 (API) ，该名开发者将能根据相同的经验与原则把相似的对接门径运用在系统的其他资源上”

资源 (Resoruce) 是 REST 架构的核心，系统中每个特定资源皆对应着逻辑上唯一的统一资源标识符 (URI) ，且根据标识符来提供创建，撷取，编辑和删除数据的方法。

因此，为了实现统一接口 (Uniform Interface) 原则，REST 架构需具备四个接口约束 (Interface Constraints) ：

Identification of resources ：资源通过标识符辨识。
Manipulation of resources through representations ：通过 Content-Type HTTP 标头，客户端可以向服务端指定数据发送的表现形式。
Self-descriptive messages ：资源的操作方式，通过 HTTP 的标准方法来实现。
Hypermedia as the engine of application state ：应用的状态由请求端的请求方式来决定，例如：客户端可通过发送基于 POST 方法的请求来创建资源，进而改变应用的状态。

简言之，统一接口 (Uniform Interface) 原则的四个约束条件，通过标示符定义了资源，客户端向服务器指定偏好的格式，借着 HTTP 的标准方法来描述操作，进而改变应用中，特定资源的状态。

一般来说，客户端无法清楚的知道其请求对象是否是整个通信链的最终服务器。请求对象对于客户端来说，是一个抽象的多层结构，透过逻辑上分层迭代的设计，使得系统的伸缩性大为增加，并且更容易的配置各种辅助性的机制，例如：负载平衡，共享的缓存，还有强制的安全管理政策。

一般来说，服务端响应所反馈的是资源表现层的静态形式。然而在特定的情况下，通过传输一段可执行或是编译好的代码给客户端，进而达到服务器扩展或是说自订客户端特定功能的执行是被允许的。