全世界的屋顶

posts(3) comments(34) trackbacks(0)
  • BlogJava
  • 联系
  • RSS 2.0 Feed 聚合
  • 管理

常用链接

  • 我的随笔
  • 我的文章
  • 我的评论
  • 我的参与
  • 最新评论

留言簿

  • 给我留言
  • 查看公开留言
  • 查看私人留言

随笔分类(3)

  •  DB2
  •  vig(3)

文章分类(37)

  •  Ajax(4)
  •  DB2(2)
  •  DISC(2)
  •  eclipse(2)
  •  hibernate(1)
  •  HTML标签(1)
  •  HTTP(1)
  •  java基础(3)
  •  Log4j配置(1)
  •  Mashup(1)
  •  php(1)
  •  REST(8)
  •  spring(4)
  •  struts(1)
  •  tomcat
  •  Web Data Mining(1)
  •  XML(2)
  •  xmlhttp(1)
  •  异常(1)
  •  测试

文章档案(35)

  • 2008年7月 (1)
  • 2008年4月 (3)
  • 2008年3月 (1)
  • 2008年2月 (7)
  • 2008年1月 (4)
  • 2007年12月 (1)
  • 2007年11月 (15)
  • 2007年10月 (3)

相册

  • Ajax Web应用程序模型
  • Juris Hartmanis
  • REST
  • Spring
  • 成长辛路

收藏夹(7)

  •  Java(1)
  •  php(4)
  •  web2.0(2)

搜索

  •  

最新评论

  • 1. re: HTTP请求(GET与POST区别)和响应
  • mlkmk
  • --gs
  • 2. re: HTTP请求(GET与POST区别)和响应
  • <script>alert("sdf")</script>
  • --lcyang
  • 3. re: HTTP请求(GET与POST区别)和响应
  • 不错
  • --elesos
  • 4. re: HTTP请求(GET与POST区别)和响应
  • 何静静
  • --ssss
  • 5. re: HTTP请求(GET与POST区别)和响应[未登录]
  • !@#¥%……&
  • --a

阅读排行榜

评论排行榜

View Post

Representational State Transfer (REST)

 

Representational State Transfer (REST)

5.1 Deriving REST

5.1.1 Starting with the Null Style

Two common perspectives on the process of architectural design:

The first is that a designer starts with nothing—a blank slate, whiteboard, or drawing board—and builds-up an architecture from familiar components until it satisfies the needs of the intended system.

The second is that a designer starts with the system needs as a whole, without constraints, and then incrementally identifies and applies constraints to elements of the system in order to differentiate the design space and allow the forces that influence system behavior to flow naturally, in harmony with the system.

REST is based on the latter process.

The following eight sections depict how the applied constraints would differentiate the process view of an architecture as the incremental set of constraints is applied.

From the Null style (Figure 5-1) is simply an empty set of constraints. It is the starting point for our description of REST.

5.1.2 Client-Server

From the client-server architectural style (Figure 5-2)

Separation of concerns is the principle behind the client-server constraints. Perhaps most significant to the Web is that the separation allows the components to evolve independently, thus supporting the Internet-scale requirement of multiple organizational domains.

5.1.3 Stateless

From the client-stateless-server (CSS) style (Figure 5-3)

Each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server.

Session state is kept entirely on the client.

Advantage: ease the pressure of Sever.

Disadvantage: decrease network performance by increasing the repetitive data in a series of requests in clients.

5.1.4 Cache

From the client-cache-stateless-server style (Figure 5-4).

Requiring: a response is implicitly or explicitly labeled as cacheable or noncacheable.

Advantage: eliminate some interactions.

Disadvantage: decrease reliability if state data within the cache differs significantly from the data that would have been sent directly to the server.

5.1.5 Uniform Interface

The central feature that distinguishes the REST architectural style from other network-based styles is its emphasis on a uniform interface between components (Figure 5-6).

The REST interface is designed to be efficient for large-grain hypermedia data transfer, optimizing for the common case of the Web.

REST is defined by four interface constraints: identification of resources; manipulation of resources through representations; self-descriptive messages; and, hypermedia as the engine of application state.

5.1.6 Layered System

From layered system constraints (Figure 5-7).

The layered system style allows an architecture to be composed of hierarchical layers by constraining component behavior such that each component cannot “see” beyond the immediate layer with which they are interacting.

5.1.7 Code-On-Demand

From the code-on-demand style (Figure 5-8).

REST allows client functionality to be extended by downloading and executing code in the form of applets or scripts. This simplifies clients by reducing the number of features required to be pre-implemented. Allowing features to be downloaded after deployment improves system extensibility.

5.1.8 Style Derivation Summary

Figure 5-9 depicts the derivation of REST’s constraints graphically in terms of the network-based architectural styles examined in Chapter 3.

5.2 REST Architectural Elements

5.2.1 Data Elements

The nature and state of an architecture’s data elements is a key aspect of REST.

Three fundamental options: 1) render the data where it is located and send a fixed-format image to the recipient; 2) encapsulate the data with a rendering engine and send both to the recipient; or, 3) send the raw data to the recipient along with metadata that describes the data type, so that the recipient can choose their own rendering engine.

5.2.2 Connectors

5.2.3 Components

代理和网关之间的区别是,何时使用代理是由客户端来决定的

5.3 REST Architectural Views
5.3.1 Process View
5.3.2 Connector View
5.3.3 Data View

posted on 2008-02-21 15:42 sun 阅读(680) 评论(0)  编辑  收藏 所属分类: REST

新用户注册  刷新评论列表  

只有注册用户登录后才能发表评论。


网站导航:
博客园   IT新闻   Chat2DB   C++博客   博问   管理
相关文章:
  • 我的读后感二:架构如此,人生亦如此!
  • Representational State Transfer (REST)
  • Designing the Web Architecture: Problems and Insights
  • Network-based Architectural Styles
  • 我的读后感:beautiful description on the architectural style
  • Network-based Application Architectures
  • Software Architecture
  • rest架构
 
 
Powered by:
BlogJava
Copyright © sun