REST 与 SOAP巅峰对话

跟着Restful的盛行，soap如同有点贵族落寞了。下面我们先具体分析一下他们的各自的特征。 Restful 简介 REST（Representational State Transfer）是 Roy Fielding 提出的一个描写互联络统架构特性的名词。为什么称为 REST？Web 本质上由林林总总的资源组成，资源由 URI 仅有标识。浏览器（或许任何其它类似于浏览器的运用程序）将展示出该资  源的一种表现方法，或许一种表现情况。如果用户在该页面中定向到指向其它资源的联接，则将访问该资源，并表现出它的情况。这意味着客户端运用程序跟着每个资源表现情况的不一样而发生情况转移，也即所谓 REST。 关于 REST 本身，本文就不再这里过多地谈论，读者可以参看 developerWorks 上其它分析 REST 的文章。本文的关键在于通过 REST 与 SOAP Web 效力的对比，帮忙读者更深刻知道 REST 架构特性的特征，优势。 Restful 描写 我们将选用遵照 REST 描写原则的 ROA（Resource-Oriented Architecture，面向资源的系统架构）进行描写。ROA 是什么？简单点说，ROA 是一种把实践疑问转换成 REST 式 Web 效力的方法，它使得 URI、HTTP 和 XML 具有跟其他 Web 运用一样的作业方法。 在运用 ROA 进行描写时，我们需要把真实的运用需要转化成 ROA 中的资源，根柢上遵照以下的进程： 分析运用需要中的数据集。 映射数据集到 ROA 中的资源。 关于每一资源，命名它的 URI。 为每一资源描写其 Representations。 用 hypermedia links 表述资源间的联络。 Restful Web效力架构 SOAP架构信赖我们现已很熟了，即使不是真实的很熟，但至少早年都用过吧。web service早年风靡一时。先看看它的架构 SOAP Web架构 可以看到，与 REST 架构比较，SOAP 架构图明显不一样的是：悉数的 SOAP 消息发送都运用 HTTP POST 方法，并且悉数 SOAP 消息的 URI 都是一样的，这是根据 SOAP 的 Web 效力的根柢实习特征。 ? Restful Web效力 与 SOAP Web效力 对比 接口抽象 RESTful Web 效力运用标准的 HTTP 方法 (GET/PUT/POST/DELETE) 来抽象悉数 Web 系统的效力才干，而不一样的是，SOAP 运用都通过定义自己特性化的接口方法来抽象 Web 效力，这更像我们常常谈到的 RPC。例如本例中的 getUserList 与 getUserByName 方法。 RESTful Web 效力运用标准的 HTTP 方法优势，从大的方面来讲：标准化的 HTTP 操作方法，联络其他的标准化技术，如 URI，HTML，XML 等，将会极大前进系统与系统之间联络的互操作才干。尤其在 Web 运用领域，RESTful Web 效力所表达的这种抽象才干更加接近 Web 本身的作业方法，也更加天然。 一同，运用标准 HTTP 方法完结的 RRESTful Web 效力也带来了 HTTP 方法本身的一些优势： 无情况性（Stateless） HTTP 协议从本质上说是一种无情况的协议，客户端宣告的 HTTP 央求之间可以相互隔绝，不存在相互的情况依托。根据 HTTP 的 ROA，以非常天然的方法来完结无情况效力央求处置逻辑。关于分布式的运用而言，尽情给定的两个效力央求 Request 1 与 Request 2, 由于它们之间并没有相互之间的情况依托，就不需要对它们进行相互协作处置，其结果是：Request 1 与 Request 2 可以在任何的效力器上实行，这样的运用很简单在效力器端支撑负载平衡 (load-balance)。 安全操作与幂指相等特性（Safety /Idempotence） HTTP 的 GET、HEAD 央求本质上应该是安全的调用，即：GET、HEAD 调用不会有任何的副作用，不会构成效力器端情况的改动。关于效力器来说，客户端对某一 URI 做 n 次的 GET、HAED 调用，其情况与没有做调用是一样的，不会发生任何的改动。 HTTP 的 PUT、DELTE 调用，具有幂指相等特性 , 即：客户端对某一 URI 做 n 次的 PUT、DELTE 调用，其效果与做一次的调用是一样的。HTTP 的 GET、HEAD 方法也具有幂指相等特性。 HTTP 这些标准方法在原则上保证你的分布式系统具有这些特性，以帮忙构建更加健旺的分布式系统。 安全控制 为了说明疑问，根据上面的在线用户处理系统，我们给定以下场景： 参看一开始我们给出的用例图，关于客户端 Client2，我们只希望它能以只读的方法访问 User 和 User List 资源，而 Client1 具有访问悉数资源的悉数权限。 怎样做这样的安全控制？ 通行的做法是：悉数从客户端 Client2 宣告的 HTTP 央求都通过署理效力器 (Proxy Server)。署理效力器拟定安全策略：悉数通过该署理的访问 User 和 User List 资源的央求只具有读取权限，即：容许 GET/HEAD 操作，而像具有写权限的 PUT/DELTE 是不被容许的。 如果关于 REST，我们看看这样的安全策略是怎样安置的。如下图所示： 一般署理效力器的完结根据 (URI, HTTP Method) 两元组来抉择 HTTP 央求的安全合法性。 当发现类似于（{username}，DELETE）这样的央求时，予以拒绝。 关于 SOAP，如果我们想借助于既有的署理效力器进行安全控制，会比较尴尬，如下图： 悉数的 SOAP 消息通过署理效力器，只能看到（ HTTP POST）这样的信息，如果署理效力器想知道其时的 HTTP 央求具体做的是什么，有必要对 SOAP 的消息体解码，这样的话，意味着需要第三方的署理效力器需要知道其时的 SOAP 消息语义，而这种 SOAP 运用与署理效力器之间的紧耦合联络是不合理的。 ? 关于缓存 众所周知，关于根据网络的分布式运用，网络传输是一个影响运用功用的重要要素。怎样运用缓存来节省网络传输带来的开支，这是每一个构建分布式网络运用的开发人员有必要考虑的疑问。 HTTP 协议带条件的 HTTP GET 央求 (Conditional GET) 被描写用来节省客户端与效力器之间网络传输带来的开支，这也给客户端完结 Cache 机制 ( 包含在客户端与效力器之间的任何署理 ) 供应了可以。HTTP 协议通过 HTTP HEADER 域：If-Modified-Since/Last- Modified，If-None-Match/ETag 完结带条件的 GET 央求。 REST 的运用可以充分地开掘 HTTP 协议对缓存支撑的才干。当客户端第一次发送 HTTP GET 央求给效力器获得内容后，该内容可以被缓存效力器 (Cache Server) 缓存。当下一次客户端央求一样的资源时，缓存可以直接给出照应，而不需要央求远程的效力器获得。而这悉数对客户端来说都是透明的。 而关于 SOAP，情况又是怎么的呢？ 运用 HTTP 协议的 SOAP，由于其描写原则上并不像 REST 那样侧重与 Web 的作业方法相共同，所以，根据 SOAP 运用很难充分发挥 HTTP 本身的缓存才干。 两个要素抉择了根据 SOAP 运用的缓存机制要远比 REST 凌乱： 其一、悉数通过缓存效力器的 SOAP 消息总是 HTTP POST，缓存效力器如果不解码 SOAP 消息体，无法知道该 HTTP 央求能否是想从效力器获得数据。 其二、SOAP 消息所运用的 URI 总是指向 SOAP 的效力器，如本文比方中的 ，这并没有表达真实的资源 URI，其结果是缓存效力器根柢不知道那个资源正在被央求，更不用谈进行缓存处置。 关于联接 在一个纯的 SOAP 运用中，URI 本质上除了用来指示 SOAP 效力器外，本身没有任何意义。与 REST 的不一样的是，无法通过 URI 驱动 SOAP 方法调用。例如在我们的比方中，当我们通过 getUserList SOAP 消息获得悉数的用户列表后，仍然无法通过既有的信息得到某个具体的用户信息。仅有的方法只需通过 WSDL 的指示，通过调用 getUserByName 获得，getUserList 与 getUserByName 是相互孤立的。 而关于 REST，情况是完全不一样的：通过  URI 获得用户列表，然后再通过用户列表中所供应的 LINK 特色，例如 tester获得 tester 用户的用户信息。这样的作业方法，非常类似于你在浏览器的某个页面上点击某个 hyperlink, 浏览器帮你自动定向到你想访问的页面，并不依托任何第三方的信息。 ? 总结 典型的根据 SOAP 的 Web 效力以操作为中心，每个操作接受 XML 文档作为输入，供应 XML 文档作为输出。在本质上讲，它们是 RPC 特性的。而在遵照 REST 原则的 ROA 运用中，效力是以资源为中心的，对每个资源的操作都是标准化的 HTTP 方法。 本文首要会合在以上的几个方面，对 SOAP 与 REST 进行了对比，可以看到，根据 REST 构建的系统其系统的扩展才干要强于 SOAP，这可以表现在它的共同接口抽象、署理效力器支撑、缓存效力器支撑等诸多方面。并且，伴跟着 Web Site as Web Services 演进的趋势，根据 REST 描写和完结的简单性和强扩展性，有理由信赖，REST 将会成为 Web 效力的一个重要架构实习领域。 ? ?