智慧建筑集成技术中的HTTP绑定及REST映射

HTTP 绑定指定OBIX 请求到HTTP 的简单REST 映射。例如，读取请求是一个简单的HTTP GET，这意味着用户可以通过在浏览器中键入对象的URI 来简单地读取对象。有关HTTP 1.1 的完整规范，请参阅RFC 2616。

基于REST 的Web 服务的主要特征之一是以遵循RFC 2616 定义的协议的方式显式使用HTTP 方法。例如，HTTP GET 被定义为数据产生方法，旨在由客户端应用程序用于检索资源以从Web 服务器获取数据，或者执行某个查询并预期Web 服务器将查找某一组匹配资源，然后使用该资源进行响应。

REST 要求开发人员显式地使用HTTP 方法，并且使用方式与协议定义一致。这个基本REST 设计原则建立了创建、读取、更新和删除（Create，Read，Update and Delete，CRUD）操作与HTTP 方法之间一对一映射。根据此映射：

（1）若要在服务器上创建资源，应该使用POST 方法。

（2）若要检索某个资源，应该使用GET 方法。

（3）若要更改资源状态或对其进行更新，应该使用PUT 方法。

（4）若要删除某个资源，应该使用DELETE 方法。

许多Web API 中所固有的一个令人遗憾的设计缺陷在于将HTTP 方法用于非预期用途。例如，HTTP GET 请求中的请求URI 通常标识一个特定的资源。或者，请求URI 中的查询字符串包括一组参数，这些参数定义服务器用于查找一组匹配资源的搜索条件。至少，HTTP/1.1 RFC 是这样描述GET 方法的。但是在许多情况下，不优雅的Web API 使用 HTTP GET 来触发服务器上的事务性操作—— 例如，向数据库添加记录。在这些情况下，GET 请求URI 属于不正确使用，或者至少不是以基于REST 的方式使用。如果Web API 使用GET 调用远程过程，则应该类似如下：(www.xing528.com)

这不是非常优雅的设计，因为上面的Web 方法支持通过HTTP GET 进行状态更改操作。换句话说，该HTTP GET 请求具有副作用。如果处理成功，则该请求的结果是向基础数据存储区添加一个新用户—— 在此例中为Robert。这里的问题主要在语义上。Web 服务器旨在通过检索与请求URI 中的路径（或查询条件）匹配的资源，并在响应中返回这些资源或其表示形式，从而响应HTTP GET请求，而不是向数据库添加记录。从该协议方法的预期用途的角度看，然后再从与HTTP/1.1 兼容的Web 服务器的角度看，以这种方式使用GET 是不一致的。

除了语义之外，GET 的其他问题在于，为了触发数据库中记录的删除、修改或添加，或者以某种方式更改服务器端状态，它请求Web 缓存工具（爬网程序）和搜索引擎简单地通过对某个链接进行爬网处理，从而意外地做出服务器端更改。克服此常见问题的简单方法是将请求URI 上的参数名称和值转移到XML 标记中。这样产生的标记是要创建的实体的XML 表示形式，可以在 HTTP POST 的正文中进行发送，此HTTP POST 的请求URI 是该实体的预期父实体（见图7-2 中的清单1 和2）。

图7-2　基于REST 的HTTP 请求示例

上述方法是基于REST 的请求的示例：正确使用HTTP POST 并将有效负载包括在请求的正文中。在接收端，可以通过将正文中包含的资源添加为请求URI中标识的资源的从属资源，从而处理该请求；在此例下，应该将新资源添加为/users 的子项。POST 请求中指定的这种新实体与其父实体之间的包含关系类似于某个文件从属于其父目录的方式。客户端设置实体与其父实体之间的关系，并在POST 请求中定义新实体的URI。

REST 并非始终是正确的选择。它作为一种设计Web 服务的方法而变得流行，这种方法对专有中间件（如某个应用程序服务器）的依赖比基于SOAP 和WSDL 的方法更少。在某种意义上，通过强调URI 和HTTP 等早期Internet 标准，REST 是对大型应用程序服务器时代之前的Web 方式的回归。正如已经在所谓的基于REST 的接口设计原则中研究过的一样，XML over HTTP 是一个功能强大的接口，允许内部应用程序[如基于Asynchronous JavaScript+XML（Ajax）的自定义用户界面]轻松连接、定位和使用资源。