Programmable Web及其分类
在编写计算机程序时，我们经常需要使用第三方库中的算法。但是有时我们需要获得由数据驱动的而且数据无法容易获得的服务，这时我们需要依赖于programmable web。这里programmable web是跟human web相对的。human web指的是传统的面向人类使用的web，如人们浏览的网站返回HTML文档显式供人类查看，而programmable web指的是面向计算机程序使用的web，比如web服务等，一般返回更加规则的结果，如XML文档，JSON文档等作为程序的输入。本质上programmable web在工作方式上跟human web是一致的，都是发送请求后，获得所需要的输出或操作。
programmable web是基于HTTP和XML技术的，虽然HTML,JSON等也在使用，但是使用较多的还是XML。
programmable web分类主要是指可以根据调用web服务的方式和形式不同的技术进行分类，如基于RPC(SOAP+WSDL), REST, REST-RPC混合等方式。到这里还是非常的抽象，要对programmable web进行分类，首先来回顾一下programmable web的一些技术。
HTTP
HTTP是一种基于文档的协议。客户端把文档放在信封里，然后发送给服务器。接收到请求后，服务器解析请求并作为回应，把相应文档放在信封里，然后发送给客户端。HTTP对信封格式有严格标准，但是并不关心信封里面的内容，一般是有客户端或服务端解析。
一个HTTP GET请求：
1 | GET /index.html HTTP/1.1 |
HTTP请求主要有下面几个组成部分：
HTTP方法：表示客户端希望服务器如何处理该信封。
路径：这里是URI里主机名(hostname)后面的部分。
请求报头：一组key-value pairs，作为元数据。
实体主体，也就是文档，这里GET请求是没有主体的，POST请求会将请求参数放在这里，而GET请求会请求参数以键值对形式直接放在URI中。
HTTP相应也是一个放在信封里的文档，如下：
1 | HTTP/1.1 200 OK |
HTTP响应可分为三个部分：
HTTP响应代码
响应报头
实体主体
方法信息
HTTP是Programmable Web上所有服务所共有的。而Web服务之间的差别的形成，是由于在两个问题上的做法有所不同。只要了解一个Web服务器是如何处理这两个问题的，就可以清楚地直到该服务是否跟Web的理念保持一致。
第一个问题是：客户端如何把自己的意图传达给服务器，也就是客户希望进行什么操作，如获取数据、删除数据还是改写数据。这种关于对数据采取什么操作的信息，称为方法信息(method information)。
RESTful Web Services的方式是把它放在HTTP方法中(HTTP method)，包括主要的GET, HEAD, PUT, DELETE和POST。通过这些方法足以分辨操作类型，标准化的名称是一个很好的优点。
RPC方式是通过提供另外的方法描述提供method information，如在URI中的参数(RPC-REST混合模式)，在SOAP信封中调用WSDS中定义的方法(SOAP-RPC)。而不关注请求时的HTTP method，RPC-REST混合模式中可能总是使用GET，尽管实际的操作可能是DELETE，SOAP-RPC可能总是使用POST(需要包含SOAP信息进行服务调用)，尽管实际的操作可能是PUT。
Google搜索服务的WSDL文档片断：
1 | <operation name="doGoogleSearch"> |
一个SOAP RPC调用的HTTP请求
1 | POST search/beta2 HTTP/1.1 |
第二个问题是：客户端如何告诉服务器对哪些数据进行操作。也就是作用域信息(scoping information)。
作用域信息
很多Web服务器都把作用域信息放在URI路径里。
另一种选择是把作用域信息放在实体主体里，SOAP Web服务通常采用这种方式。
采用了什么样的服务设计，决定了哪些信息属于方法信息，哪些信息属于作用域信息，即使功能相同。
1 | 请求(GET) http://flickr.com/photos/tags/penguin |
两者实现的功能相同，请求也都是GET，但是后者在uri参数中制定了调用的方法名flickr.photos.search，令HTTP的GET方法失去了原本用意，也就是实际上的操作并不不受GET或POST影响。前一个例子中Google SOAP API中也是如此，在SOAP信封中制定了调用的方法甚至参数。
相互竞争的服务架构
不同Web服务会有不同做法，目前主要有三种常见的Web服务架构：REST式架构、RPC式架构和REST-RPC混合架构。
RPC式架构通过一个复杂的、编程语言式的接口，来暴露其内部算法。而ROA则通过一个简单的、文档处理接口，来暴露其内部数据。
REST式、面向资源的机构(Resource-Oriented Architectures)
REST式架构意味着，方法信息都在HTTP方法里；面向资源的架构(ROA)意味着，作用域信息都在URI里，二者结合起来可以非常强大。一个面向资源的REST式Web服务，通过HTTP请求第一行就能基本了解客户端需要做什么了。如果HTTP方法跟方法信息对不上，那么服务就不算事RESTful的；如果作用域信息不放在URI里，那么服务就不是面向资源的。
RPC式架构(RPC-Style Architectures)
RPC式Web服务通常从客户端收到一个包括方法信息和作用域信息的信封，然后发回回复信封。一种常用的信封格式是SOAP，进一步封装杂HTTP信封中。SOAP信封内容随着调用方法和参数不同有所变化，但是HTTP信封格式总是不变的，同样的uri，同样的HTTP method(一般总是POST)。SOAP-RPC服务为采用HTTP的很多特性，只暴露一个URI，并且只支持一种HTTP方法(POST方法)。而REST服务为不同的作用域信息暴露不同的URI。
除了SOAP RPC，更宽泛的是XML-RPC，SOAP其实就是基于XML，不过多了一系列规范和相应的技术栈，包括WSDL,UDDI.
REST-RPC混合架构
1 | http://api.flickr.com/services/rest/?method=flickr.photos.search&tags=penguin |
这里的服务调用将作用域信息放在URI中，有些类似于REST，但是不同的是其将方法信息也放在URI中了，所以本质上是一个RPC式服务，只是将URI当做信封格式来用。
许多只读的Web服务，尽管起初是按照RPC风格设计的，但都可以被认为是完全REST式和面向资源的。但是如果服务允许DELETE等操作的话，就会出现客户端所使用的HTTP方法与正在想执行的操作不一致的情况，就失去了REST的特征，所以称为REST-RPC混合服务。
Programmable Web涉及的技术
HTTP
所有Web服务都用HTTP，只是使用方式有所不同。
URI
同样的，所有Web服务都用HTTP，但使用方式有所不同。一个REST服务为客户端可能操作的每一个数据暴露一个URI；一个REST-RPC混合服务为客户端可行进行的每个操作暴露一个URI；一个RPC服务为每个远程处理暴露一个相同的URI，即服务的端点(endpoint)。
XML-RPC
用XML表达函数调用及其返回值，专门用于RPC式Web服务，现在已经逐渐被更完善的SOAP技术栈所替代。
SOAP
基于XML的信封格式，同样是为RPC提供方法信息和作用域信息。
WSDL
WSDL(web service description language)，web服务描述语言，是一套用于描述SOAP WEB服务的XML词汇。客户端可以通过参考WSDL文档，可以确切的知道可以调用哪些RPC式方法，需要哪些参数，以及返回值数据类型。SOAP的服务都发布有WSDL文档，否则很难使用。
WADL
WADL(web applicaiotn description language), web应用描述语言，是一套用于描述REST式服务的XML词汇。提供的功能与WSDL类似，但是由于REST式服务接口比较简单，其必要性没有像WSDL至于SOAP-RPC那么大。