Rest风格WEB服务(Rest Style Web Service)的真相

写这篇文章是目的不是介绍Web-Service, 而是从Restful Web Service提及来剖析一下

什么才是真正的Restful Style的架构与协议，从而更好的理解web服务的设计理念与架

构本质。

一：Web Service基础知识

一个最简单web服务就一个web页面等待请求与处理。更容易理解的方式是Web 

Service能够把一个应用变成一个基本WEB方式的请求与处理的应用。常见的两种

Web Service处理方式为：

a.      基于WSDL/SOAP的方式

b.      Rest方式

方式a是比较正统的，客户端调用必须先取得WSDL文件，而后生成调用的API才可

以使用。它不是我要说的重点，基本调用流程以下：

方式b是Rest方式，Rest的Web Service的设计原则是基于CRUD，其支持四种操做分

别为：

GET – 获取信息/请求信息内容，绝大多数浏览器获取信息时使用该方式。

POST – 增长信息内容，显示之前的信息内容，能够看做是insert操做

PUT – 更新信息内容，至关与update

DELETE – 删除信息内容能够看做是delete

 

Rest方式更加简单便捷，若是从设计原则上看HTTP协议自己已是最Restful风格的

协议了HTTP协议很好的支持了CRUD的操做。正是由于如此，WEB2.0以来, 基于

Restful的Web Service愈来愈多的成为首选。

 

二：认识RestfulStyle

Rest的全称是可表述状态迁移(RepresentationalState Transfer), 可能从字面看有点奇怪

HTTP协议自己无状态协议，其保持链接经过设置请求头字段Connection: keep-alive与

设置过时时间来同时控制。其实Rest方式的WebService也是无状态的这样作的好处最少

有如下两个：

1.      更好的负载平衡，减轻服务器端负担

2.      更快的客户端响应，减小没必要要的状态检查。

 

Restful 风格的兴起，要感谢互联网巨头Google,Facebook等他们提供大量基于Restful

风格的web服务，从谷歌地图到天气预报到翻译，国内的互联网巨头腾讯，新浪微博也

发布自己的web服务，吸引更多的开发者加入他们的阵营。Rest除了知足基本的CRUD

设计原则之外，还要遵循以下约定：

1.      资源操做能够经过描述来实现即Representation

2.      消息自己是无状态与自我描述(传输支持XML与JSON)

3.      能够发送与接受多个Representation

 

Rest风格(Restful Style)架构原则：

1.      客户服务器方式

2.      无状态协议传输

3.      支持缓存

4.      统一接口定义

5.      分层系统设计

这样发布了Rest的Web服务API其改变不会影响到客户端程序与实现。若是你的系统

不能适用Rest风格的架构怎么办，从新设计一个新的架构，扩展Rest风格架构。可是

这个世界上绝大数的系统与应用要作的事情就是CRUD。

 

三. Rest与HTTP

上面已经提到过HTTP协议多是最Rest风格的协议，而HTTP1.1协议设计的一个原则

就要实现Rest风格。因此毫无疑问HTTP的GET, POST, PUT, DELETE就是最好的证实

可是Rest风格是否能够应用到其它一些协议与系统设计中嘛，答案是确定的，一个最好

的例子证实就POP3协议, POP3支持Fetch 数据记录，查询记录，更新记录与删除记录

(记录表明email)多么完美的Rest风格协议。

已经存在的HTTP协议应用：

1.      浏览器客户端(你每天上网，不是IE就是Chrome，或者其它浏览器，你懂的)

2.      即时消息通讯，MSN/Skype支持

3.      各类内容管理系统

4.      博客系统与微博客户端应用。

5.      你能够来补充/？

 

Rest消息详解:

1.      跟咱们如今知道的HTTP URI没有什么分别，Google静态地图就是一个很好的例子

         只是URL加上不一样参数就能够fetch不一样的地图内容。

2.      能够支持任何类型的数据传输，这点与基于XML与JSON的信息传输有点同，后者

         更希望传输文本内容与结构化文本内容

3.      SOAP与XML-RPC有严格的消息格式限制，rest没有消息格式要求。客户端调用方

         便啊！

 

Rest风格Web服务的好处，显然易见一个好处就是简化了客户端的调用，再也不像WSDL

那般麻烦。从而减低第三方开发者的学习成本，减短了学习曲线。有利于服务推广与普

及，吸引更多用户数量从而带来潜在的商业利益。

 

在软件即服务(SaaS - Software As A Service)与软件即平台(PasS-Platform 

As A Service)中有着重要的地位与应用。这正是那些互联网巨头对Rest风

格感兴趣的缘由之一。

 

四：Rest风格架构

Rest风格能够用在非WEB的系统设计与架构中嘛/?打答案是确定的，Rest能够用在任何

系统设计中，从本质是上Rest不是一种技术，而是一种架构原则，固然能够用来架构非

WEB的系统。系统越大风格越要象Rest方式如此才是一个成功的架构。

 

WEB中的面向对象编程

ExtJS, KendoUI(基于JQuery)等JavaScript库已经支持很是方便的从URL中fetch内容

更新数据，前端设计愈来愈趋向于更加细化的分层设计，而不只仅是MVC。客户端

程序员应该更多的专一前台用户体验，因为这些框架良好的封装与可扩展行，

JavaScript等语言编程越来越多的引入面向对象的概念与实践。能够好不夸张的说如

今的JavaScript编程与十年以前已经有本质不一样。

（原博客地址）

==============================================

网上的说法：

• REST是一种针对网络应用的设计和开发方式，能够下降开发的复杂性，提升系统的可伸缩性。REST提出了一些设计概念和准则：
• 1. 网络上的全部事物都被抽象为资源（resource）；
  2. 每一个资源对应一个惟一的资源标识（resource identifier）；
  3. 经过通用的链接器接口（generic connector interface）对资源进行操做；
  4. 对资源的各类操做不会改变资源标识；
  5. 全部的操做都是无状态的（stateless）。

这阵子正打算用Rails作个东东，因此开始系统地学习起了Rails。巧合的是，大概两周前，dlee邀请我加入Fielding博士关于REST的那篇论文的翻译团队。能够说Rails和REST这两个最热门的词汇几乎同时挤入了个人生活。随着我对Rails的学习和对[Fielding]的翻译，我也开始对REST产生了一些不太成熟的想法，写在这里与你们分享，同时也起到抛砖引玉的做用，欢迎你们讨论。

先复习一下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就会成为你的开发利器。

原文