RESTful Web Service 架构

特点：简单，可靠，高效，跨平台和跨语言

含义：

• Web Service 简单来说是指提供给不同设备通过互联网（一般使用 HTTP 协议）进行通信和交换数据的一种服务。RESTful Web Service 是实现 Web Service 的一种方式。
• REST (Representational State Transfer)，是一种架构方式和约定，和具体实现无关，也不一定必须基于Web。一般把采用 REST 架构的 Web Service 称之 RESTful Web Service，严格来说，我们应该称这种 Web Service 为具有 REST 风格的 Web Service，不是协议，没有规定传输消息的具体格式，简单和轻量级。如：例如都使用HTTP传输，使用风格类似的 URL 作为 API 和 使用 JSON 或者 XML 来传输数据等等（目前 JSON 占据主导地位，并且有持续流行的趋势）。
• 使用 SOAP 的 Web Service 实际上是以协议（protocol）的形式工作的。SOAP Web Service 严格规定了如何发现和描述 API，其传输的消息也有严格统一的格式（例如传输的载体XML有严格的格式规范）

REST 架构约定

• CS结构（Client–server）服务端和客户端之间遵守相同的接口规范。在遵守相同接口规范的前提下，二者都可以独立演化，甚至可以被其它的实现替代。服务器不跟踪客户端的状态（分页的实现/Facebook API）提高了服务器的可扩展性（scalability）
• 无状态（Stateless）任何时候一个客户端的请求数据都包含能够让服务端完成请求的充分信息，服务端不依赖前后不同请求的顺序和状态信息来完成请求。请求的session信息由客户端持有，并在必要时连同请求数据一起发送。服务端可以使用请求中的session信息去其它外部服务或者数据库获取相关内容进以便对该请求做权限验证等操作，提高了系统的健壮性（reliability），但也造成了传输数据的冗余性。
• 缓存机制（Cacheable），提高服务器的效率和性能
• 系统分层（Layered system），提高了系统的可扩展性，方便我们管理不同资源的权限，有利于提高系统的安全性
• 可定制代码（可选）（Code on demand）
• 一致的接口（Uniform interface），降低子系统之间的耦合度，子系统只要关注实现接口即可，在保证接口一致的情况下，不同的实现可以各自独立演化。
  • 一致的数据格式：比如 Web Service 请求返回格式要么是 HTML，要么是 XML，要么是 JSON，不能返回服务端自己内部使用的特殊格式。
  • 可以对已有数据进一步操作（Resource Identifiers）：通常我们只要在返回的数据中包含一个 UID 即可做到这点。比如从服务端获得了一个订单数据，这个订单数据里应该保证有一个唯一的订单 ID，当我们想对这个订单进行进一步操作时，可以保障操作的是同一个订单。
  • 数据具有自我描述性：比如通过HTTP返回的数据里面有 [MIME type ]信息，我们从MIME type里面可以知道数据的具体格式，是图片，视频还是JSON。
  • 应用系统状态变化只依赖超媒体（Hypermedia）：应用系统状态变化只依赖于服务端发来的Hypermedia（如超链接 hyperlinks）。举例来说，假设向一个微博 Web Service 请求一条微博信息，服务端响应信息中应该包含和这条微博相关的其它的URL。客户端可以进一步利用这些URL发起请求来获取感兴趣的信息。