RESTfulWebService架构剖析.docxVIP

RESTful Web Service 架构剖析 　本文内容具有一定的专业偏向性，主要面向对 Web Service 有一定理解，需要进一步了解基于 REST 形式的 Web Service 的 IT 开发人员和架构师。它不是一个知识的入门介绍，你需要较多相关领域的知识背景才能理解全部内容。 　　什么是 RESTful Web Service 　　作为互联网应用开发人员，我们经常能看到 Web Service，REST 和 RESTful Web Service 之类的描述，可我们真的清楚这些概念吗? 　　Web Service 简单来说是指提供给不同设备通过互联网(一般使用 HTTP 协议)进行通信和交换数据的一种服务。RESTful Web Service 是实现 Web Service 的一种方式。那么到底什么是 RESTful Web Service呢?什么又是 REST 呢? 　　REST 和 RESTful Web Service 　　REST (Representational State Transfer) 是由美国计算机科学家 Roy Fielding在2000年的博士论文提出的一种架构方式。Roy Fielding绝对可以称之为业界大牛，他现任 Adobe 首席科学家，是HTTP协议的首要作者之一，也是Apache项目的联合创始人。 　　REST 是一种架构方式和约定，和具体实现无关，也不一定必须基于Web。我们一般把采用 REST 架构的 Web Service 称之 RESTful Web Service。在实际项目应用中，严格来说，我们应该称这种 Web Service 为具有 REST 风格的 Web Service。原因是我们在处理和解决某些实际问题时，这种 Service 可能并不完全严格遵守 REST 架构的所有必要约定。 　　RESTful Web Service 和基于SOAP的 Web Services 有着本质的不同。使用 SOAP 的 Web Service 实际上是以协议(protocol)的形式工作的。因为 SOAP Web Service 严格规定了如何发现和描述 API，其传输的消息也有严格统一的格式(例如传输的载体XML有严格的格式规范)。而 RESTful Web Service 并不是协议，它没有规定传输消息的具体格式，它只是一种约定使用 REST 架构实现的 Web Service。RESTful Web Service 相比SOAP Web Service 更加简单和轻量级。现在大部分 RESTful Web Service 都使用类似的形式，例如都使用HTTP传输，使用风格类似的 URL 作为 API 和 使用 JSON 或者 XML 来传输数据等等(目前 JSON 占据主导地位，并且有持续流行的趋势[1])。 　　如果你之前没有接触过SOAP，你只需记住RESTful Web Service 是一种采用 REST 架构约定，更简单，更轻量级的Web Service 　　REST 之父大牛 Roy Fielding 在他的论文中，一共从下面6个方面阐述了 REST 架构的约定(REST 应该满足哪些条件，以及这样做会有什么好处) 　　REST 架构约定 　　CS结构(Client–server) 　　客户端是一个相对独立的实现，它不必考虑数据的持久化存储问题。服务端拥有和保存数据，服务端不去关心客户端内部实现，也不用关心客户端请求的上下文。服务端和客户端之间遵守相同的接口规范。在遵守相同接口规范的前提下，二者都可以独立演化，甚至可以被其它的实现替代。 　　无状态(Stateless) 　　任何时候一个客户端的请求数据都包含能够让服务端完成请求的充分信息，服务端不依赖前后不同请求的顺序和状态信息来完成请求。请求的session信息由客户端持有，并在必要时连同请求数据一起发送。服务端可以使用请求中的session信息去其它外部服务或者数据库获取相关内容进以便对该请求做权限验证等操作。 　　如果所需数据要通过多次请求才能完成，客户端必须自己负责记录状态(因为服务器不跟踪客户端的状态)，在下次请求时附带发出。一个典型的例子是分页的实现，客户端需要自己保存当前页数，请求下一页时作为参数一起发给服务端，服务端使用该参数返回正确的下一页数据。有些设计，比如Facebook API，服务端返回数据中包含下一页数据的请求URL，客户端只要记录这个URL即可发起下一页的请求。 　　服务端不依赖客户端的请求顺序和状态提高了服务器的可扩展性(scalability)。比如在使用Load balancer的情况下，不能因为某个请求被分配到其它服务器而丢失某些信息从而返回不正确的数据。