REST 阅读 (1) - Software Architecture

Representational State Transfer (REST)

REST Constraints

Null ->  Client-Server -> client-stateless-server ->
client-cache-stateless-server -> Uniform-client-cache-stateless-server ->
Uniform-Layered-client-cache-stateless-server ->
code-on-demand(optional) - Uniform-Layered-client-cache-stateless-server

REST Architectural Elements

Data Elements

resource ------------------ the intended conceptual target of a hypertext reference
resource identifier ----------------- URL, URN
representation ---------------------- HTML document, JPEG image
representation metadata media type -- last-modified time
resource metadata ------------------- source link, alternates, vary
control data ------------------------ if-modified-since, cache-control

架构样式和基于网络的软件架构的设计

Roy Thomas Fielding


摘 要


万维网（WWW）已经取得很大的成功，因为它的架构设计满足了互联网级别的分布式超媒体系统的需求。Web已被迭代式的开发了十几年，对定义其架构的标准进行了一系列的修改。为了识别需要修改的和不需要修改的哪些方面，我们需要一种现在web架构模型来引导它的设计、定义和开发。

软件架构的研究寻找了很多方法来决定怎样最优地划分系统，组件彼此如何识别和通信，信息如何沟通，系统元素如何独立进化，以及上面这些问题如何通过正式的和非正式的概念描述。受这种需求的驱动，我的工作就是要利用一些原则上的约束来理解和评估基于网络的软件架构，从而期望满足该架构的功能、性能和社会的需求。一种架构样式是一种有名字的和一组架构约束等价的概念。

本文定义了一种通过架构样式来理解基于网络的软件架构的框架，并阐述了该样式是如何引导基于网络的软件架构的设计的。我对基于网络的软件架构的样式进行了调查研究，并根据他们的促进分布式超媒体架构的属性对他们进行分析。然后我就引入了REST样式，并解释该样式是如何引导现代web软件架构的设计何开发的。

REST强调组件交互的伸缩性，接口的通用性，组件开发的独立性，减少交互时间的中间组件，增强安全，兼容遗留系统。

1. Software Architecture
1.1 Run-time Abstraction
A software architecture is an abstraction of the run-time elements of a software system during some phase of its operation. A system may be composed of many levels of abstraction and many phases of operation, each with its own software architecture.

Therefore, architectural design and source code structural design, though closely related, are separate design activities.
1.2 Elements
A software architecture is defined by a configuration of architectural elements—components, connectors, and data—constrained in their relationships in order to achieve a desired set of architectural properties.
1.2.1 Components
A component is an abstract unit of software instructions and internal state that provides a transformation of data via its interface.

Example transformations include loading into memory from secondary storage, performing some calculation, translating to a different format, encapsulation with other data, etc.

A component is defined by its interface and the services it provides to other components, rather than by its implementation behind the interface.
1.2.2 Connectors
A connector is an abstract mechanism that mediates communication, coordination, or cooperation among components.
Examples include shared representations, remote procedure calls, message-passing protocols, and data streams.

Connectors enable communication between components by transferring data elements from one interface to another without changing the data.
1.2.3 Data
A datum is an element of information that is transferred from a component, or received by a component, via a connector.

Examples include byte-sequences, messages, marshaled parameters, and serialized objects, but do not include information that is permanently resident or hidden within a component.

The nature of the data elements within a network-based application architecture will often determine whether or not a given architectural style is appropriate.
1.3 Configurations
A configuration is the structure of architectural relationships among components, connectors, and data during a period of system run-time.
Strictly speaking, one might think of a configuration as being equivalent to a set of specific constraints on component interaction.
1.4 Properties
The set of architectural properties of a software architecture includes all properties that derive from the selection and arrangement of components, connectors, and data within the system. Examples include both the functional properties achieved by the system and non-functional properties, such as relative ease of evolution, reusability of components, efficiency, and dynamic extensibility, often referred to as quality attributes.
1.5 Styles
An architectural style is a coordinated set of architectural constraints that restricts the roles/features of architectural elements and the allowed relationships among those elements within any architecture that conforms to that style.
1.6 Patterns and Pattern Languages

1.7 Views
An architectural viewpoint is often application-specific and varies widely based on the application domain. ... we have seen architectural viewpoints that address a variety of issues, including: temporal issues, state and control approaches, data representation, transaction life cycle, security safeguards, and peak demand and graceful degradation. No doubt there are many more possible viewpoints.
A process view emphasizes the data flow through the components and some aspects of the connections among the components with respect to the data. A data view emphasizes the processing flow, with less emphasis on the connectors. A connection view emphasizes the relationship between components and the state of communication.