REST
Rest初探
一种思维方式影响了软件行业的发展。REST软件架构是当今世界上最成功的互联网的超媒体分布式系统。它让人们真正理解我们的网络协议HTTP本来面貌。它正在成为网络服务的主流技术，同时也正在改变互联网的网络软件开发的全新思维方式。AJAX技术和Rails框架把REST软件架构思想真正地在实际中很好表现出来。今天微软也已经应用REST并且提出把我们现有的网络变成为一个语义网，这种网络将会使得搜索更加智能化。
REST与HTTP协议
REST软件架构是由Roy Thomas Fielding博士在2000年首次提出的。他为我们描绘了开发基于互联网的网络软件的蓝图。REST软件架构是一个抽象的概念，是一种为了实现这一互联网的超媒体分布式系统的行动指南。利用任何的技术都可以实现这种理念。而实现这一软件架构最著名的就是HTTP协议。通常我们把REST也写作为REST/HTTP，在实际中往往把REST理解为基于HTTP的REST软件架构，或者更进一步把REST和HTTP看作为等同的概念。
今天，HTTP是互联网上应用最广泛的计算机协议。HTTP不是一个简单的运载数据的协议，而是一个具有丰富内涵的网络软件的协议。它不仅仅能够对于互联网资源进行唯一定位，而且还能告诉我们对于该资源进行怎样运作。这也是REST软件架构当中最重要的两个理念。而REST软件架构理念是真正理解HTTP协议而形成的。有了REST软件架构理念出现，才使得软件业避免了对HTTP协议的片面理解。只有正确的理论指导，才能避免在软件开发的实际工作过程中少走弯路。
REST与URI（资源定位）
REST软件架构之所以是一个超媒体系统，是因为它可以把网络上所有资源进行唯一的定位，不管你的文件是图片、文件Word还是视频文件，也不管你的文件是txt文件格式、xml文件格式还是其它文本文件格式。它利用支持HTTP的TCP/IP协议来确定互联网上的资源。
REST与CRUD原则
REST软件架构遵循了CRUD原则，该原则告诉我们对于资源（包括网络资源）只需要四种行为：创建（Create）、获取（Read）、更新（Update）和销毁（DELETE）就可以完成对其操作和处理了。其实世界万物都是遵循这一规律：生、变、见、灭。所以计算机世界也不例外。这个原则是源自于我们对于数据库表的数据操作：insert（生）、select（见）、update（变）和delete（灭），所以有时候CRUD也写作为 RUDI，其中的I就是insert。这四个操作是一种原子操作，即一种无法再分的操作，通过它们可以构造复杂的操作过程，正如数学上四则运算是数字的最基本的运算一样。
REST与网络服务
尽管在Java语言世界中网络服务目前是以SOAP技术为主，但是REST将是是网络服务的另一选择，并且是真正意义上的网络服务。基于REST思想的网络服务不久的将来也会成为是网络服务的主流技术。REST不仅仅把HTTP作为自己的数据运输协议，而且也作为直接进行数据处理的工具。而当前的网络服务技术都需要使用其它手段来完成数据处理工作，它们完全独立于HTTP协议来进行的，这样增加了大量的复杂软件架构设计工作。REST的思想充分利用了现有的HTTP技术的网络能力。在德国电视台上曾经出现过一个这样的五十万欧元智力题：如何实现网络服务才能充分利用现有的HTTP协议？该问题给出了四个答案：去问微软；WSDL2.0/SOAP1.2；WS-Transfer；根本没有。这个问题告诉我们HTTP并不是一个简单的数据传来传去的协议，而是一个聪明的会表现自己的协议，这也许是REST = Representational State Transfer的真正含义。
实际上目前很多大公司已经采用了REST技术作为网络服务，如Google、Amazon等。在Java语言中重要的两个以SOAP技术开始的网络服务框架XFire和Axis也把REST作为自己的另一种选择。它们的新的项目分别是Apache CXF 和Axis2 。Java语言也制定关于REST网络服务规范：JAX-RS: Java API for RESTful Web Services (JSR 311)。相信还会出现更多与REST相关的激动人心的信息。
REST与AJAX技术
尽管AJAX技术的出现才不到两年时间，但是AJAX技术遵循了REST的一些重要原则。AJAX技术充分利用了HTTP来获取网络资源并且实现了 HTTP没有的对于异步数据进行传输的功能。AJAX技术还使得软件更好地实现分布性功能，在一个企业内只要一个人下载了AJAX引擎，其它企业内部的人员，就可以共享该资源了。AJAX技术遵守REST准则的应用程序中简单和可伸缩的架构，凡是采用AJAX技术的页面简洁而又丰富，一个页面表现了丰富多彩的形态。
AJAX技术还使用了一种不同于XML格式的JSON文件格式，这个意义在哪里呢？在REST软件架构下我们不能对于XML文件进行序列化处理，这样程序员必须要使用自己的XML绑定框架。而以序列化的JavaScript对象为基础的JSON已经获得了广泛认可，它被认为能以远比XML更好的方式来序列化和传输简单数据结构，而且它更简洁。这对REST是一个极大贡献和补充。
当前的网络应用软件还违背了REST的“无状态服务器”约束。REST服务器只知道自己的状态。REST不关心客户端的状态，客户端的状态自己来管理，这是AJAX技术的应用之地。通过AJAX技术，可以发挥有状态网络客户机的优势。而REST的服务器关心的是从所有网络客户端发送到服务器操作的顺序。这样使得互联网这样一个巨大的网络得到有序的管理。
REST与Rails框架
Ruby on Rails框架（简称Rails或者Rails框架）是一个基于Ruby语言的越来越流行的网络应用软件开发框架。它提供了关于REST最好的支持，也是当今应用REST最成功的一个软件开发框架。Rails框架（从版本1.2.x起）成为了第一个引入REST作为核心思想的主流网络软件开发框架。在 Rails框架的充分利用了REST软件架构之后，人们更加坚信REST的重要性和必要性。Rails利用REST软件架构思想对网络服务也提供了一流的支持。从最直观的角度看待REST，它是网络服务最理想的手段，但是Rails框架把REST带到了网络应用软件开发框架。这是一次飞跃，让REST的思想从网络服务的应用提升到了网络应用软件开发。利用REST思想的simply_restful插件已经成为了Rails框架的核心内容。
REST安全性
我们把现有基于SOAP的网络服务和基于REST/HTTP网络服务作个比喻，前者是一种传统的寄信方式，而后者是现代网络的电子邮件方式。要是是寄信和电子邮件都有病毒存在的话，传统的寄信被送到对方就很危险，而电子邮件是开发的，电子邮件供应商比如Google为我们检查了电子邮件是否有病毒。这里并不是说明SOAP网络服务消息包含义病毒，而是说明HTTP是无法处理SOAP信息包究竟好不好，需要额外的软件工具解决这一问题，包括防火墙也用不上和管不了。
REST/HTTP网络服务的信息包可以被防火墙理解和控制。你可以按照操作和链接进行过滤信息包，如你可以规定从外部来的只能读取（GET操作）自己服务器的资源。这样对于系统管理员而言使得软件管理更为简单。REST的安全性还可以利用传输安全协议SSL/TLS、基本和摘要式认证（Basic und Digest Authentication）。除了这些REST自身的安全性功能外，还可以利用像基于信息的Web Services Security（JSR 155）作为REST不错的补充。
参考文献
中文参考文献
* http://www.ibm.com/developerworks/cn/web/wa-ajaxarch/
* http://www.ibm.com/developerworks/cn/java/j-cb08016/
Roy Thomas Fielding博士论文中文版本
* http://e2c.91yee.com/columns/
Roy Thomas Fielding博士论文英文版本
* http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
先复习一下REST的基本思想。[Fielding]把REST形式化地定义为一种架构风格（architecture style），它有架构元素（element）和架构约束（constraint）组成。这些概念比较晦涩难懂，而且我们做工程的往往并不需要形而上的理解。我们只知道，REST是一种针对网络应用的设计和开发方式，可以降低开发的复杂性，提高系统的可伸缩性。REST提出了一些设计概念和准则：
1. 网络上的所有事物都被抽象为资源（resource）；
2. 每个资源对应一个唯一的资源标识（resource identifier）；
3. 通过通用的连接器接口（generic connector interface）对资源进行操作；
4. 对资源的各种操作不会改变资源标识；
5. 所有的操作都是无状态的（stateless）。
对于当今最常见的网络应用来说，resource identifier是url，generic connector interface是HTTP，第4条准则就是我们常说的url不变性。这些概念中的resouce最容易使人产生误解。resouce所指的并不是数据，而是数据+特定的表现形式（representation），这也是为什么REST的全名是Representational State Transfer的原因。举个例子来说，“本月卖得最好的10本书”和“你最喜欢的10本书”在数据上可能有重叠（有一本书即卖得好，你又喜欢），甚至完全相同。但是它们的representation不同，因此是不同的resource。
REST之所以能够简化开发，是因为其引入的架构约束，比如Rails 1.2中对REST的实现默认把controller中的方法限制在7个：index、show、new、edit、create、update和 destory，这实际上就是对CURD的实现。更进一步讲，Rails（也是当今大部分网络应用）使用HTTP作为generic connector interface，HTTP则把对一个url的操作限制在了4个之内：GET、POST、PUT和DELETE。
REST之所以能够提高系统的可伸缩性，是因为它强制所有操作都是stateless的，这样就没有context的约束，如果要做分布式、做集群，就不需要考虑context的问题了。同时，它令系统可以有效地使用pool。REST对性能的另一个提升来自其对client和server任务的分配： server只负责提供resource以及操作resource的服务，而client要根据resource中的data和 representation自己做render。这就减少了服务器的开销。
既然REST有这样的好处，那我们应该义无反顾地拥抱它啊！目前一些大牛（像DHH）都已经开始投入到了REST的世界，那我们这些人应该做什么或者说思考写什么你呢？我觉得我们应该思考两个问题：
1. 如何使用REST；
2. REST和MVC的关系。
第一个问题假设REST是我们应该采用的架构，然后讨论如何使用；第二个问题则要说明REST和当前最普遍应用的MVC是什么关系，互补还是取代？
我们先来谈谈第一个问题，如何使用REST。我感觉，REST除了给我们带来了一个崭新的架构以外，还有一个重要的贡献是在开发系统过程中的一种新的思维方式：通过url来设计系统的结构。根据REST，每个url都代表一个resource，而整个系统就是由这些resource组成的。因此，如果 url是设计良好的，那么系统的结构就也应该是设计良好的。对于非高手级的开发人员来说，考虑一个系统如何架构总是一个很抽象的问题。敏捷开发所提倡的 Test Driven Development，其好处之一（我觉得是最大的好处）就是可以通过testcase直观地设计系统的接口。比如在还没有创建一个class的时候就编写一个testcase，虽然设置不能通过编译，但是testcase中的方法调用可以很好地从class使用者的角度反映出需要的接口，从而为 class的设计提供了直观的表现。这与在REST架构中通过url设计系统结构非常类似。虽然我们连一个功能都没有实现，但是我们可以先设计出我们认为合理的url，这些url甚至不能连接到任何page或action，但是它们直观地告诉我们：系统对用户的访问接口就应该是这样。根据这些url，我们可以很方便地设计系统的结构。
让我在这里重申一遍：REST允许我们通过url设计系统，就像Test Driven Development允许我们使用testcase设计class接口一样。
OK，既然url有这样的好处，那我们就着重讨论一下如何设计url。网络应用通常都是有hierarchy的，像棵大树。我们通常希望url也能反映出资源的层次性。比如对于一个blog应用：/articles表示所有的文章，/articles/1表示id为1的文章，这都比较直观。遗憾的是，网络应用的资源结构永远不会如此简单。因此人们常常会问这样一个问题：RESTful的url能覆盖所有的用户请求吗？比如，login如何RESTful？search如何RESTful？
从REST的概念上来看，所有可以被抽象为资源的东东都可以使用RESTful的url。因此对于上面的两个问题，如果login和search可以被抽象为资源，那么就可以使用RESTful的url。search比较简单，因为它会返回搜索结果，因此可以被抽象为资源，并且只实现index方法就可以了（只需要显示搜索结果，没有create、destory之类的东西）。然而这里面也有一个问题：search的关键字如何传给server？ index方法显然应该使用HTTP GET，这会把关键字加到url后面，当然不符合REST的风格。要解决这个问题，可以把每次search看作一个资源，因此要创建create和 index方法，create用来在用户点击“搜索”按钮是通过HTTP POST把关键字传给server，然后index则用来显示搜索结果。这样一来，我们还可以记录用户的搜索历史。使用同样的方法，我们也可以对 login应用REST，即每次login动作是一个资源。
现在，我们来复杂一些的东东。如何用url表达“category为ruby的article”？一开始可能想到的是 /category/ruby/articles，这种想法很直观。但是我觉得里面的category是不需要的，我们可以直接把“/ruby”理解为 “category是ruby”，也就是说“ruby”出现的位置说明了它指的就是category。OK，/ruby/articles，单单从这个 url上看，我们能获得多少关于category的信息呢？显然category隐藏在了url后面，这样做到底好不好，应该是仁者见仁，智者见智了。对于如何表达category这样的东西，我还没想出很好的方式，大家有什么好idea，可以一起讨论。
另外还有一种url形式，它对应到程序中的继承关系。比如product是一个父类，book和computer是其子类。那么所有产品的url应该是 /products，所有书籍的url应该是/books，所有电脑的url应该是/computers。这一想法就比较直观了，而且再次验证了url可以帮助我们进行设计的论点。
让我再说明一下我的想法：如果每个用户需求都可以抽象为资源，那么就可以完全使用REST。
由此看来，使用REST的关键是如何抽象资源，抽象得越精确，对REST的应用就越好。因此，如何改变我们目前根深蒂固的基于action的思想是最重要的。
有了对第一个问题的讨论，第二个问题就容易讨论多了。REST会取代MVC吗？还是彼此是互补关系（就像AOP对于OOP）？答案是It depends！如果我们可以把所有的用户需求都可以抽象为资源，那么MVC就可以推出历史的舞台了。如果情况相反，那么我们就需要混合使用REST和 MVC。
当然，这是非常理想的论断。可能我们无法找到一种方法可以把所有的用户需求都抽象为资源，因为保证这种抽象的完整性（即真的是所有需求都可以）需要形式化的证明。而且即使被证明出来了，由于开发人员的能力和喜好不同，MVC肯定也会成为不少人的首选。但是对于希望拥抱REST的人来说，这些都没有关系。只要你开发的系统所设计的问题域可以被合理地抽象为资源，那么REST就会成为你的开发利器。
所以，所有希望拥抱REST的朋友们，赶快训练自己如何带上资源的眼镜看世界吧，这才是REST的核心所在。
REST的架构设计
REST（Representational State Transfer）是一种轻量级的Web Service架构风格，其实现和操作明显比SOAP和XML-RPC更为简洁，可以完全通过HTTP协议实现，还可以利用缓存Cache来提高响应速度，性能、效率和易用性上都优于SOAP协议。
REST架构遵循了CRUD原则，CRUD原则对于资源只需要四种行为：Create（创建）、Read（读取）、Update（更新）和Delete（删除）就可以完成对其操作和处理。这四个操作是一种原子操作，即一种无法再分的操作，通过它们可以构造复杂的操作过程，正如数学上四则运算是数字的最基本的运算一样。
REST架构让人们真正理解我们的网络协议HTTP本来面貌，对资源的操作包括获取、创建、修改和删除资源的操作正好对应HTTP协议提供的GET、POST、PUT和DELETE方法，因此REST把HTTP对一个URL资源的操作限制在GET、POST、PUT和DELETE这四个之内。这种针对网络应用的设计和开发方式，可以降低开发的复杂性，提高系统的可伸缩性。
REST的设计准则
REST架构是针对Web应用而设计的，其目的是为了降低开发的复杂性，提高系统的可伸缩性。REST提出了如下设计准则：
网络上的所有事物都被抽象为资源（resource）；
每个资源对应一个唯一的资源标识符（resource identifier）；
通过通用的连接器接口（generic connector interface）对资源进行操作；
对资源的各种操作不会改变资源标识符；
所有的操作都是无状态的（stateless）。
使用REST架构
对于开发人员来说，关心的是如何使用REST架构，这里我们来简单谈谈这个问题。REST不仅仅是一种崭新的架构，它带来的更是一种全新的Web开发过程中的思维方式：通过URL来设计系统结构。REST是一套简单的设计原则、一种架构风格（或模式），不是一种具体的标准或架构。REST有很多成功的使用案例，著名的Delicious和Flickr都提供基于REST风格的API使用，客户端调用也极其方便，下面是我用ASP写的一个很简单的REST举例，从中可以看出REST是多么的简单易用。
客户端代码：
Private Function httpGet(url, method, data)
Dim xmlhttp
Set xmlhttp = Server.CreateObject("MSXML2.ServerXMLHTTP")
xmlhttp.open method, url + "?" + data, False
xmlhttp.setRequestHeader "Content-Type", "application/x-www-form-urlencoded; charset=UTF-8"
xmlhttp.setRequestHeader "Content-Length", Len(data)
xmlhttp.send (Null)
If (xmlhttp.Status = 200) Then httpGet = xmlhttp.responseText
Set xmlhttp = Nothing
End Function
Private Function httpPost(url, method, data)
Dim xmlhttp
Set xmlhttp = Server.CreateObject("MSXML2.ServerXMLHTTP")
xmlhttp.open method, url, False
xmlhttp.setRequestHeader "Content-Type", "application/x-www-form-urlencoded; charset=UTF-8"
xmlhttp.setRequestHeader "Content-Length", Len(data)
xmlhttp.send (data)
If (xmlhttp.Status = 200) Then httpPost = xmlhttp.responseText
Set xmlhttp = Nothing
End Function
Private Function httpPut(url, method, data)
Dim xmlhttp
Set xmlhttp = Server.CreateObject("MSXML2.ServerXMLHTTP")
xmlhttp.open method, url, False
xmlhttp.setRequestHeader "Content-Type", "application/x-www-form-urlencoded; charset=UTF-8"
xmlhttp.setRequestHeader "Content-Length", Len(data)
xmlhttp.send (data)
If xmlhttp.Status >= 400 And xmlhttp.Status <= 599 Then
response.write " Error Occurred : " & xmlhttp.Status & " - " & xmlhttp.statusText
Else
response.write xmlhttp.responseText
End If
If (xmlhttp.Status = 200) Then httpPut = xmlhttp.responseText
Set xmlhttp = Nothing
End Function
Private Function httpDelete(url, method, data)
Dim xmlhttp
Set xmlhttp = Server.CreateObject("MSXML2.ServerXMLHTTP")
xmlhttp.open method, url + "?" + data, False
xmlhttp.setRequestHeader "Content-Type", "application/x-www-form-urlencoded; charset=UTF-8"
xmlhttp.setRequestHeader "Content-Length", Len(data)
xmlhttp.send (Null)
If xmlhttp.Status >= 400 And xmlhttp.Status <= 599 Then
response.write " Error Occurred : " & xmlhttp.Status & " - " & xmlhttp.statusText
Else
response.write xmlhttp.responseText
End If
If (xmlhttp.Status = 200) Then httpDelete = xmlhttp.responseText
Set xmlhttp = Nothing
End Function
response.write httpPost("http://localhost/rest/service.asp", "POST", "do=POST")
response.write httpGet("http://localhost/rest/service.asp", "GET", "do=GET")
response.write httpPut("http://localhost/rest/service.asp", "PUT", "do=PUT")
response.write httpDelete("http://localhost/rest/service.asp", "DELETE", "do=DELETE")
服务端代码：
Response.Write Request.ServerVariables("REQUEST_METHOD")
If (Request.ServerVariables("REQUEST_METHOD")="GET") Then
Response.Write "DO GET" + Request("do")
ElseIf (Request.ServerVariables("REQUEST_METHOD")="POST") Then
Response.Write "DO POST" + Request("do")
ElseIf (Request.ServerVariables("REQUEST_METHOD")="PUT") Then
Response.Write "DO PUT" + Request("do")
ElseIf (Request.ServerVariables("REQUEST_METHOD")="DELETE") Then
Response.Write "DO DELETE" + Request("do")
End if
需要注意的是，IIS服务器默认是不支持ASP文件的PUT和DELETE操作，默认会返回“403 - Forbidden”错误，因此需要修改IIS的设置，修改方法是：管理根据－IIS信息服务器－网站－属性－主目录－应用程序配置－配置－映射，选择 ASP － 编辑 － 修改为全部动作。
关于更多关于REST方面的知识，建议阅读《RESTful Web Services》这本书。
原创文章如转载，请注明：转载自月光博客 [ http://www.williamlong.info/ ]
一种思维方式影响了软件行业的发展。REST软件架构是当今世界上最成功的互联网的超媒体分布式系统。它让人们真正理解我们的网络协议HTTP本来面貌。它正在成为网络服务的主流技术，同时也正在改变互联网的网络软件开发的全新思维方式。AJAX技术和Rails框架把REST软件架构思想真正地在实际中很好表现出来。今天微软也已经应用REST并且提出把我们现有的网络变成为一个语义网，这种网络将会使得搜索更加智能化。
REST与HTTP协议
REST软件架构是由Roy Thomas Fielding博士在2000年首次提出的。他为我们描绘了开发基于互联网的网络软件的蓝图。REST软件架构是一个抽象的概念，是一种为了实现这一互联网的超媒体分布式系统的行动指南。利用任何的技术都可以实现这种理念。而实现这一软件架构最著名的就是HTTP协议。通常我们把REST也写作为REST/HTTP，在实际中往往把REST理解为基于HTTP的REST软件架构，或者更进一步把REST和HTTP看作为等同的概念。
今天，HTTP是互联网上应用最广泛的计算机协议。HTTP不是一个简单的运载数据的协议，而是一个具有丰富内涵的网络软件的协议。它不仅仅能够对于互联网资源进行唯一定位，而且还能告诉我们对于该资源进行怎样运作。这也是REST软件架构当中最重要的两个理念。而REST软件架构理念是真正理解HTTP协议而形成的。有了REST软件架构理念出现，才使得软件业避免了对HTTP协议的片面理解。只有正确的理论指导，才能避免在软件开发的实际工作过程中少走弯路。
REST与URI（资源定位）
REST软件架构之所以是一个超媒体系统，是因为它可以把网络上所有资源进行唯一的定位，不管你的文件是图片、文件Word还是视频文件，也不管你的文件是txt文件格式、xml文件格式还是其它文本文件格式。它利用支持HTTP的TCP/IP协议来确定互联网上的资源。
REST与CRUD原则
REST软件架构遵循了CRUD原则，该原则告诉我们对于资源（包括网络资源）只需要四种行为：创建（Create）、获取（Read）、更新（Update）和销毁（DELETE）就可以完成对其操作和处理了。其实世界万物都是遵循这一规律：生、变、见、灭。所以计算机世界也不例外。这个原则是源自于我们对于数据库表的数据操作：insert（生）、select（见）、update（变）和delete（灭），所以有时候CRUD也写作为 RUDI，其中的I就是insert。这四个操作是一种原子操作，即一种无法再分的操作，通过它们可以构造复杂的操作过程，正如数学上四则运算是数字的最基本的运算一样。
REST与网络服务
尽管在Java语言世界中网络服务目前是以SOAP技术为主，但是REST将是是网络服务的另一选择，并且是真正意义上的网络服务。基于REST思想的网络服务不久的将来也会成为是网络服务的主流技术。REST不仅仅把HTTP作为自己的数据运输协议，而且也作为直接进行数据处理的工具。而当前的网络服务技术都需要使用其它手段来完成数据处理工作，它们完全独立于HTTP协议来进行的，这样增加了大量的复杂软件架构设计工作。REST的思想充分利用了现有的HTTP技术的网络能力。在德国电视台上曾经出现过一个这样的五十万欧元智力题：如何实现网络服务才能充分利用现有的HTTP协议？该问题给出了四个答案：去问微软；WSDL2.0/SOAP1.2；WS-Transfer；根本没有。这个问题告诉我们HTTP并不是一个简单的数据传来传去的协议，而是一个聪明的会表现自己的协议，这也许是REST = Representational State Transfer的真正含义。
实际上目前很多大公司已经采用了REST技术作为网络服务，如Google、Amazon等。在Java语言中重要的两个以SOAP技术开始的网络服务框架XFire和Axis也把REST作为自己的另一种选择。它们的新的项目分别是Apache CXF 和Axis2 。Java语言也制定关于REST网络服务规范：JAX-RS: Java API for RESTful Web Services (JSR 311)。相信还会出现更多与REST相关的激动人心的信息。
REST与AJAX技术
尽管AJAX技术的出现才不到两年时间，但是AJAX技术遵循了REST的一些重要原则。AJAX技术充分利用了HTTP来获取网络资源并且实现了 HTTP没有的对于异步数据进行传输的功能。AJAX技术还使得软件更好地实现分布性功能，在一个企业内只要一个人下载了AJAX引擎，其它企业内部的人员，就可以共享该资源了。AJAX技术遵守REST准则的应用程序中简单和可伸缩的架构，凡是采用AJAX技术的页面简洁而又丰富，一个页面表现了丰富多彩的形态。
AJAX技术还使用了一种不同于XML格式的JSON文件格式，这个意义在哪里呢？在REST软件架构下我们不能对于XML文件进行序列化处理，这样程序员必须要使用自己的XML绑定框架。而以序列化的JavaScript对象为基础的JSON已经获得了广泛认可，它被认为能以远比XML更好的方式来序列化和传输简单数据结构，而且它更简洁。这对REST是一个极大贡献和补充。
当前的网络应用软件还违背了REST的“无状态服务器”约束。REST服务器只知道自己的状态。REST不关心客户端的状态，客户端的状态自己来管理，这是AJAX技术的应用之地。通过AJAX技术，可以发挥有状态网络客户机的优势。而REST的服务器关心的是从所有网络客户端发送到服务器操作的顺序。这样使得互联网这样一个巨大的网络得到有序的管理。
REST与Rails框架
Ruby on Rails框架（简称Rails或者Rails框架）是一个基于Ruby语言的越来越流行的网络应用软件开发框架。它提供了关于REST最好的支持，也是当今应用REST最成功的一个软件开发框架。Rails框架（从版本1.2.x起）成为了第一个引入REST作为核心思想的主流网络软件开发框架。在 Rails框架的充分利用了REST软件架构之后，人们更加坚信REST的重要性和必要性。Rails利用REST软件架构思想对网络服务也提供了一流的支持。从最直观的角度看待REST，它是网络服务最理想的手段，但是Rails框架把REST带到了网络应用软件开发框架。这是一次飞跃，让REST的思想从网络服务的应用提升到了网络应用软件开发。利用REST思想的simply_restful插件已经成为了Rails框架的核心内容。
REST安全性
我们把现有基于SOAP的网络服务和基于REST/HTTP网络服务作个比喻，前者是一种传统的寄信方式，而后者是现代网络的电子邮件方式。要是是寄信和电子邮件都有病毒存在的话，传统的寄信被送到对方就很危险，而电子邮件是开发的，电子邮件供应商比如Google为我们检查了电子邮件是否有病毒。这里并不是说明SOAP网络服务消息包含义病毒，而是说明HTTP是无法处理SOAP信息包究竟好不好，需要额外的软件工具解决这一问题，包括防火墙也用不上和管不了。
REST/HTTP网络服务的信息包可以被防火墙理解和控制。你可以按照操作和链接进行过滤信息包，如你可以规定从外部来的只能读取（GET操作）自己服务器的资源。这样对于系统管理员而言使得软件管理更为简单。REST的安全性还可以利用传输安全协议SSL/TLS、基本和摘要式认证（Basic und Digest Authentication）。除了这些REST自身的安全性功能外，还可以利用像基于信息的Web Services Security（JSR 155）作为REST不错的补充。
参考文献
中文参考文献
* http://www.ibm.com/developerworks/cn/web/wa-ajaxarch/
* http://www.ibm.com/developerworks/cn/java/j-cb08016/
Roy Thomas Fielding博士论文中文版本
* http://e2c.91yee.com/columns/
Roy Thomas Fielding博士论文英文版本
* http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
先复习一下REST的基本思想。[Fielding]把REST形式化地定义为一种架构风格（architecture style），它有架构元素（element）和架构约束（constraint）组成。这些概念比较晦涩难懂，而且我们做工程的往往并不需要形而上的理解。我们只知道，REST是一种针对网络应用的设计和开发方式，可以降低开发的复杂性，提高系统的可伸缩性。REST提出了一些设计概念和准则：
1. 网络上的所有事物都被抽象为资源（resource）；
2. 每个资源对应一个唯一的资源标识（resource identifier）；
3. 通过通用的连接器接口（generic connector interface）对资源进行操作；
4. 对资源的各种操作不会改变资源标识；
5. 所有的操作都是无状态的（stateless）。
对于当今最常见的网络应用来说，resource identifier是url，generic connector interface是HTTP，第4条准则就是我们常说的url不变性。这些概念中的resouce最容易使人产生误解。resouce所指的并不是数据，而是数据+特定的表现形式（representation），这也是为什么REST的全名是Representational State Transfer的原因。举个例子来说，“本月卖得最好的10本书”和“你最喜欢的10本书”在数据上可能有重叠（有一本书即卖得好，你又喜欢），甚至完全相同。但是它们的representation不同，因此是不同的resource。
REST之所以能够简化开发，是因为其引入的架构约束，比如Rails 1.2中对REST的实现默认把controller中的方法限制在7个：index、show、new、edit、create、update和 destory，这实际上就是对CURD的实现。更进一步讲，Rails（也是当今大部分网络应用）使用HTTP作为generic connector interface，HTTP则把对一个url的操作限制在了4个之内：GET、POST、PUT和DELETE。
REST之所以能够提高系统的可伸缩性，是因为它强制所有操作都是stateless的，这样就没有context的约束，如果要做分布式、做集群，就不需要考虑context的问题了。同时，它令系统可以有效地使用pool。REST对性能的另一个提升来自其对client和server任务的分配： server只负责提供resource以及操作resource的服务，而client要根据resource中的data和 representation自己做render。这就减少了服务器的开销。
既然REST有这样的好处，那我们应该义无反顾地拥抱它啊！目前一些大牛（像DHH）都已经开始投入到了REST的世界，那我们这些人应该做什么或者说思考写什么你呢？我觉得我们应该思考两个问题：
1. 如何使用REST；
2. REST和MVC的关系。
第一个问题假设REST是我们应该采用的架构，然后讨论如何使用；第二个问题则要说明REST和当前最普遍应用的MVC是什么关系，互补还是取代？
我们先来谈谈第一个问题，如何使用REST。我感觉，REST除了给我们带来了一个崭新的架构以外，还有一个重要的贡献是在开发系统过程中的一种新的思维方式：通过url来设计系统的结构。根据REST，每个url都代表一个resource，而整个系统就是由这些resource组成的。因此，如果 url是设计良好的，那么系统的结构就也应该是设计良好的。对于非高手级的开发人员来说，考虑一个系统如何架构总是一个很抽象的问题。敏捷开发所提倡的 Test Driven Development，其好处之一（我觉得是最大的好处）就是可以通过testcase直观地设计系统的接口。比如在还没有创建一个class的时候就编写一个testcase，虽然设置不能通过编译，但是testcase中的方法调用可以很好地从class使用者的角度反映出需要的接口，从而为 class的设计提供了直观的表现。这与在REST架构中通过url设计系统结构非常类似。虽然我们连一个功能都没有实现，但是我们可以先设计出我们认为合理的url，这些url甚至不能连接到任何page或action，但是它们直观地告诉我们：系统对用户的访问接口就应该是这样。根据这些url，我们可以很方便地设计系统的结构。
让我在这里重申一遍：REST允许我们通过url设计系统，就像Test Driven Development允许我们使用testcase设计class接口一样。
OK，既然url有这样的好处，那我们就着重讨论一下如何设计url。网络应用通常都是有hierarchy的，像棵大树。我们通常希望url也能反映出资源的层次性。比如对于一个blog应用：/articles表示所有的文章，/articles/1表示id为1的文章，这都比较直观。遗憾的是，网络应用的资源结构永远不会如此简单。因此人们常常会问这样一个问题：RESTful的url能覆盖所有的用户请求吗？比如，login如何RESTful？search如何RESTful？
从REST的概念上来看，所有可以被抽象为资源的东东都可以使用RESTful的url。因此对于上面的两个问题，如果login和search可以被抽象为资源，那么就可以使用RESTful的url。search比较简单，因为它会返回搜索结果，因此可以被抽象为资源，并且只实现index方法就可以了（只需要显示搜索结果，没有create、destory之类的东西）。然而这里面也有一个问题：search的关键字如何传给server？ index方法显然应该使用HTTP GET，这会把关键字加到url后面，当然不符合REST的风格。要解决这个问题，可以把每次search看作一个资源，因此要创建create和 index方法，create用来在用户点击“搜索”按钮是通过HTTP POST把关键字传给server，然后index则用来显示搜索结果。这样一来，我们还可以记录用户的搜索历史。使用同样的方法，我们也可以对 login应用REST，即每次login动作是一个资源。
现在，我们来复杂一些的东东。如何用url表达“category为ruby的article”？一开始可能想到的是 /category/ruby/articles，这种想法很直观。但是我觉得里面的category是不需要的，我们可以直接把“/ruby”理解为 “category是ruby”，也就是说“ruby”出现的位置说明了它指的就是category。OK，/ruby/articles，单单从这个 url上看，我们能获得多少关于category的信息呢？显然category隐藏在了url后面，这样做到底好不好，应该是仁者见仁，智者见智了。对于如何表达category这样的东西，我还没想出很好的方式，大家有什么好idea，可以一起讨论。
另外还有一种url形式，它对应到程序中的继承关系。比如product是一个父类，book和computer是其子类。那么所有产品的url应该是 /products，所有书籍的url应该是/books，所有电脑的url应该是/computers。这一想法就比较直观了，而且再次验证了url可以帮助我们进行设计的论点。
让我再说明一下我的想法：如果每个用户需求都可以抽象为资源，那么就可以完全使用REST。
由此看来，使用REST的关键是如何抽象资源，抽象得越精确，对REST的应用就越好。因此，如何改变我们目前根深蒂固的基于action的思想是最重要的。
有了对第一个问题的讨论，第二个问题就容易讨论多了。REST会取代MVC吗？还是彼此是互补关系（就像AOP对于OOP）？答案是It depends！如果我们可以把所有的用户需求都可以抽象为资源，那么MVC就可以推出历史的舞台了。如果情况相反，那么我们就需要混合使用REST和 MVC。
当然，这是非常理想的论断。可能我们无法找到一种方法可以把所有的用户需求都抽象为资源，因为保证这种抽象的完整性（即真的是所有需求都可以）需要形式化的证明。而且即使被证明出来了，由于开发人员的能力和喜好不同，MVC肯定也会成为不少人的首选。但是对于希望拥抱REST的人来说，这些都没有关系。只要你开发的系统所设计的问题域可以被合理地抽象为资源，那么REST就会成为你的开发利器。
所以，所有希望拥抱REST的朋友们，赶快训练自己如何带上资源的眼镜看世界吧，这才是REST的核心所在。
REST的架构设计
REST（Representational State Transfer）是一种轻量级的Web Service架构风格，其实现和操作明显比SOAP和XML-RPC更为简洁，可以完全通过HTTP协议实现，还可以利用缓存Cache来提高响应速度，性能、效率和易用性上都优于SOAP协议。
REST架构遵循了CRUD原则，CRUD原则对于资源只需要四种行为：Create（创建）、Read（读取）、Update（更新）和Delete（删除）就可以完成对其操作和处理。这四个操作是一种原子操作，即一种无法再分的操作，通过它们可以构造复杂的操作过程，正如数学上四则运算是数字的最基本的运算一样。
REST架构让人们真正理解我们的网络协议HTTP本来面貌，对资源的操作包括获取、创建、修改和删除资源的操作正好对应HTTP协议提供的GET、POST、PUT和DELETE方法，因此REST把HTTP对一个URL资源的操作限制在GET、POST、PUT和DELETE这四个之内。这种针对网络应用的设计和开发方式，可以降低开发的复杂性，提高系统的可伸缩性。
REST的设计准则
REST架构是针对Web应用而设计的，其目的是为了降低开发的复杂性，提高系统的可伸缩性。REST提出了如下设计准则：
网络上的所有事物都被抽象为资源（resource）；
每个资源对应一个唯一的资源标识符（resource identifier）；
通过通用的连接器接口（generic connector interface）对资源进行操作；
对资源的各种操作不会改变资源标识符；
所有的操作都是无状态的（stateless）。
使用REST架构
对于开发人员来说，关心的是如何使用REST架构，这里我们来简单谈谈这个问题。REST不仅仅是一种崭新的架构，它带来的更是一种全新的Web开发过程中的思维方式：通过URL来设计系统结构。REST是一套简单的设计原则、一种架构风格（或模式），不是一种具体的标准或架构。REST有很多成功的使用案例，著名的Delicious和Flickr都提供基于REST风格的API使用，客户端调用也极其方便，下面是我用ASP写的一个很简单的REST举例，从中可以看出REST是多么的简单易用。
客户端代码：
Private Function httpGet(url, method, data)
Dim xmlhttp
Set xmlhttp = Server.CreateObject("MSXML2.ServerXMLHTTP")
xmlhttp.open method, url + "?" + data, False
xmlhttp.setRequestHeader "Content-Type", "application/x-www-form-urlencoded; charset=UTF-8"
xmlhttp.setRequestHeader "Content-Length", Len(data)
xmlhttp.send (Null)
If (xmlhttp.Status = 200) Then httpGet = xmlhttp.responseText
Set xmlhttp = Nothing
End Function
Private Function httpPost(url, method, data)
Dim xmlhttp
Set xmlhttp = Server.CreateObject("MSXML2.ServerXMLHTTP")
xmlhttp.open method, url, False
xmlhttp.setRequestHeader "Content-Type", "application/x-www-form-urlencoded; charset=UTF-8"
xmlhttp.setRequestHeader "Content-Length", Len(data)
xmlhttp.send (data)
If (xmlhttp.Status = 200) Then httpPost = xmlhttp.responseText
Set xmlhttp = Nothing
End Function
Private Function httpPut(url, method, data)
Dim xmlhttp
Set xmlhttp = Server.CreateObject("MSXML2.ServerXMLHTTP")
xmlhttp.open method, url, False
xmlhttp.setRequestHeader "Content-Type", "application/x-www-form-urlencoded; charset=UTF-8"
xmlhttp.setRequestHeader "Content-Length", Len(data)
xmlhttp.send (data)
If xmlhttp.Status >= 400 And xmlhttp.Status <= 599 Then
response.write " Error Occurred : " & xmlhttp.Status & " - " & xmlhttp.statusText
Else
response.write xmlhttp.responseText
End If
If (xmlhttp.Status = 200) Then httpPut = xmlhttp.responseText
Set xmlhttp = Nothing
End Function
Private Function httpDelete(url, method, data)
Dim xmlhttp
Set xmlhttp = Server.CreateObject("MSXML2.ServerXMLHTTP")
xmlhttp.open method, url + "?" + data, False
xmlhttp.setRequestHeader "Content-Type", "application/x-www-form-urlencoded; charset=UTF-8"
xmlhttp.setRequestHeader "Content-Length", Len(data)
xmlhttp.send (Null)
If xmlhttp.Status >= 400 And xmlhttp.Status <= 599 Then
response.write " Error Occurred : " & xmlhttp.Status & " - " & xmlhttp.statusText
Else
response.write xmlhttp.responseText
End If
If (xmlhttp.Status = 200) Then httpDelete = xmlhttp.responseText
Set xmlhttp = Nothing
End Function
response.write httpPost("http://localhost/rest/service.asp", "POST", "do=POST")
response.write httpGet("http://localhost/rest/service.asp", "GET", "do=GET")
response.write httpPut("http://localhost/rest/service.asp", "PUT", "do=PUT")
response.write httpDelete("http://localhost/rest/service.asp", "DELETE", "do=DELETE")
服务端代码：
Response.Write Request.ServerVariables("REQUEST_METHOD")
If (Request.ServerVariables("REQUEST_METHOD")="GET") Then
Response.Write "DO GET" + Request("do")
ElseIf (Request.ServerVariables("REQUEST_METHOD")="POST") Then
Response.Write "DO POST" + Request("do")
ElseIf (Request.ServerVariables("REQUEST_METHOD")="PUT") Then
Response.Write "DO PUT" + Request("do")
ElseIf (Request.ServerVariables("REQUEST_METHOD")="DELETE") Then
Response.Write "DO DELETE" + Request("do")
End if
需要注意的是，IIS服务器默认是不支持ASP文件的PUT和DELETE操作，默认会返回“403 - Forbidden”错误，因此需要修改IIS的设置，修改方法是：管理根据－IIS信息服务器－网站－属性－主目录－应用程序配置－配置－映射，选择 ASP － 编辑 － 修改为全部动作。
关于更多关于REST方面的知识，建议阅读《RESTful Web Services》这本书。
原创文章如转载，请注明：转载自月光博客 [ http://www.williamlong.info/ ]