*REST简要介绍
首先介绍一下何为REST。REST全称呼为Representational State Transfer,中文翻译为:表述性状态转移。它不是一种框架,也不是一种规范,而是一种网络应用程序的设计风格和开发方式可以降低开发的复杂性,提高系统的可伸缩性。REST的设计原则有一下几点:
1、网络上的所有事物都被抽象为资源(Resource)。如:图片、音乐、服务
2、网络上的资源都有一个唯一标识符(Unique Identity), 即URI(Uniform Resource Identifier)
3、对资源的操作通过统一的通用接口规范(generic connector interface)来访问。如:使用HTTP标准动词GET、POSt、DELETE、PUT(CRUD)来进行访问。
4、对资源的访问不会改变它的唯一标识符,即URI不变
5、所有的操作都是无状态的(stateless)。
由于REST是基于HTTP协议的。Resouce所指的并不是数据,而是数据+特定的表现形式(representation),这也是为什么REST的全名是Representational State Transfer的原因。
REST之所以能够提高系统的可伸缩性,是因为它强制所有操作都是stateless的,这样就没有context的约束,如果要做分布式、做集群,就不需要考虑context的问题了。同时,它令系统可以有效地使用pool。REST对性能的另一个提升来自其对client和server任务的分配:server只负责提供resource以及操作resource的服务,而client要根据resource中的data和representation自己做render。这就减少了服务器的开销。
REST允许我们通过url设计系统,就像Test Driven Development允许我们使用testcase设计class接口一样。
-----------
对于基于网络的应用来说,你怎么样看待服务器,就会产生什么样的架构风格,随之产生与该架构风格相关的交互模式。
RPC架构风格将服务器看作是由一些过程组成,客户端调用这些过程来执行特定的任务。SOAP就是RPC风格的一种架构。过程是动词性的(做某件事),因此RPC建模是以动词为中心的。
分布式对象架构风格认为服务器是由一些对象和对象上的方法组成,客户端通过调用这些对象上的方法来执行特定的任务。并且客户端调用这些对象上的方法应该就像是调用本地对象上的方法一样,这样开发就可以完全按照统一的面向对象方法来做。但是很可惜,这样的抽象并不是很有效,因为分布式对象与本地对象存在着巨大的本质差别,想要掩盖这些差别很多时候甚至是有害无益的。
REST架构风格并没有试图掩盖这些差别,而是将服务器抽象为一组离散资源的集合。资源是一个抽象的概念,而不是代表某个具体的东西。注意:要真正理解REST,就一定要增强自己的抽象思维能力,充分理解到资源是抽象的。如果完全不具有抽象思维的能力,一定要将资源与数据库中的一张表或服务器端的一个文件(HTML、Servlet、JSP、etc.)一一挂起钩来,就无法真正理解REST了。资源是名词性的,因此REST建模是以名词为中心的。
REST就是专门为交互的性能和可伸缩性进行过优化的一种架构风格。而SOAP在设计的时候优先考虑的从来不是性能和可伸缩性,而是互操作性。
以上摘自REST的主要优势到底是什么?
-------------
-------------
哪些Web服务用例(use cases)体现了与REST用例的区别?它们各自应当在什么情况下采用?以及增添的Web服务复杂性在什么情况下是合理的?
也许这样的回答太过于简单化了,但我认为这是最好的概括:
如果你要用浏览器来显示XML数据,那么就采用REST;
如果你要把XML数据传给一个程序来处理,那么就采用SOAP。
目前,有些人会争辩说REST和Web服务是不同的事物;而另一些人则认为,Web服务能做的,用REST也能做。在我看来,它们就像是相同操作的不同格式。
它们之间的区别似乎可以归结为:你是否希望用浏览器来解释结果数据。
如果是的话,那么你最好还是采用REST请求(即把参数放在URL里)。
但是,如果你要用程序来解释数据的话,你还是应该采用SOAP请求,因为它是用XML消息(而不是URL)来携带参数的。
摘自REST和SOAP
-------------
REST的主要优势在我看来其实在于它是一种对于服务器的更加有效的抽象方式。
HTTP其实是在TCP/IP之上的Web的RPC.
SOAP其实也是一种的RPC,是一种基于XML的RPC.
REST和RPC/SOAP本质区别是透明性。REST透明性可以让我们以更细粒度引入伸缩性,这样以REST为主要形式可以组建一个分布式的大型架构,而这个目的恰恰是重量解决方案SOA提出的目标,现在我们有了另外一个轻量的选择。
个人感觉SOA 和 RESTful 在思想上是一样的。一个是service based,一个是resource based。 而我觉得 service 就是 resource。
我的理解: 融入式服务器端 Web 应用程序(session) --> Ajax+REST的 “有状态客户机/无状态服务器”
整体架构:
RIA + REST + Java
RIA + REST + Ruby
参考:
Ajax 和 REST,第 1 部分
Rest架构
Ajax 和 REST,第 2 部分
Ajax、REST 和 Template 混合架构应用
REST架构实质
REST真相
什么是REST架构