1、在移动互联网的大潮下，随着 docker 等技术的兴起，微服务的概念也越来越被大家接受并应用于实践，日益增多的 web service 逐渐统一于 RESTful 架构风格，如果开发者对 RESTful 架构风格不甚了解，则开发出的所谓 RESTful API 总会貌合神离，不够规范。本文是我对 RESTful 架构风格的一些理解，和大家分享一下，如果有问题，欢迎讨论。Outline 1. RESTful 架构风格o 1.1 RESTful 架构风格的特点 1.1.1 资源 1.1.2 统一接口 1.1.3 URI 1.1.4 无状态o 1.2 ROA、SOA 、REST 与 RPCo 1.3
2、 本真 REST 与 hybrid 风格 2. 认证机制o 2.1 Basic Autho 2.2 Token Autho 2.3 OAuth 3. 总结1. RESTful 架构风格RESTful 架构风格最初由 Roy T. Fielding（HTTP/1.1 协议专家组负责人）在其 2000 年的博士学位论文中提出。HTTP 就是该架构风格的一个典型应用。从其诞生之日开始，它就因其可扩展性和简单性受到越来越多的架构师和开发者们的青睐。一方面，随着云计算和移动计算的兴起，许多企业愿意在互联网上共享自己的数据、功能；另一方面，在企业中，RESTful API（也称 RESTful Web 服
3、务）也逐渐超越 SOAP 成为实现 SOA 的重要手段之一。时至今日，RESTful 架构风格已成为企业级服务的标配。REST 即 Representational State Transfer 的缩写，可译为“表现层状态转化”。REST 最大的几个特点为：资源、统一接口、URI 和无状态。1.1 RESTful 架构风格的特点1.1.1 资源所谓“资源“，就是网络上的一个实体，或者说是网络上的一个具体信息。它可以是一段文本、一张图片、一首歌曲、一种服务，总之就是一个具体的实在。资源总要通过某种载体反应其内容，文本可以用 txt 格式表现，也可以用 HTML 格式、XML 格式表现，甚至可以采
4、用二进制格式；图片可以用 JPG 格式表现，也可以用 PNG 格式表现；JSON 是现在最常用的资源表示格式。结合我的开发实践，我对资源和数据理解如下：资源是以 json(或其他 Representation)为载体的、面向用户的一组数据集，资源对信息的表达倾向于概念模型中的数据： 资源总是以某种 Representation 为载体显示的，即序列化的信息 常用的 Representation 是 json(推荐)或者 xml（不推荐）等 Represntation 是 REST 架构的表现层相对而言，数据（尤其是数据库）是一种更加抽象的、对计算机更高效和友好的数据表现形式，更多的存在于逻辑模
5、型中资源和数据关系如下：1.1.2 统一接口RESTful 架构风格规定，数据的元操作，即 CRUD(create, read, update 和 delete,即数据的增删查改)操作，分别对应于 HTTP 方法：GET 用来获取资源，POST 用来新建资源（也可以用于更新资源），PUT 用来更新资源，DELETE 用来删除资源，这样就统一了数据操作的接口，仅通过 HTTP 方法，就可以完成对数据的所有增删查改工作。即： GET（SELECT ）：从服务器取出资源（一项或多项）。 POST（CREATE ）：在服务器新建一个资源。 PUT（UPDATE ）：在服务器更新资源（客户端提供完整资源
6、数据）。 PATCH（ UPDATE）：在服务器更新资源（客户端提供需要修改的资源数据）。 DELETE（DELETE ）：从服务器删除资源。1.1.3 URI可以用一个 URI（统一资源定位符）指向资源，即每个 URI 都对应一个特定的资源。要获取这个资源，访问它的 URI 就可以，因此 URI 就成了每一个资源的地址或识别符。一般的，每个资源至少有一个 URI 与之对应，最典型的 URI 即 URL。1.1.4 无状态所谓无状态的，即所有的资源，都可以通过 URI 定位，而且这个定位与其他资源无关，也不会因为其他资源的变化而改变。有状态和无状态的区别，举个简单的例子说明一下。如查询员工的工
7、资，如果查询工资是需要登录系统，进入查询工资的页面，执行相关操作后，获取工资的多少，则这种情况是有状态的，因为查询工资的每一步操作都依赖于前一步操作，只要前置操作不成功，后续操作就无法执行；如果输入一个 url 即可得到指定员工的工资，则这种情况是 无状态的，因为获取工资不依赖于其他资源或状态，且这种情况下，员工工资是一个资源，由一个 url 与之对应，可以通过 HTTP 中的 GET 方法得到资源，这是典型的 RESTful 风格。1.2 ROA、SOA、REST 与 RPCROA 即 Resource Oriented Architecture， RESTful 架构风格的服务是围绕资源展
8、开的，是典型的 ROA 架构（虽然“A”和“架构”存在重复，但说无妨），虽然 ROA 与 SOA 并不冲突，甚至把 ROA 看做 SOA 的一种也未尝不可，但由于 RPC 也是 SOA，比较久远一点点论文、博客或图书也常把 SOA 与 RPC 混在一起讨论，因此，RESTful 架构风格的服务通常被称之为 ROA 架构，很少提及 SOA 架构，以便更加显式的与 RPC 区分。RPC 风格曾是 Web Service 的主流，最初是基于 XML-RPC 协议（一个远程过程调用（remote procedure call，RPC)的分布式计算协议），后来渐渐被 SOAP 协议（简单对象访问协议（S
9、imple Object Access Protocol）取代；RPC 风格的服务，不仅可以用 HTTP，还可以用 TCP 或其他通信协议。但 RPC 风格的服务，受开发服务采用语言的束缚比较大，如.NET 框架中，开发 web service 的传统方式是使用 WCF，基于 WCF 开发的服务即 RPC 风格的服务，使用该服务的客户端通常要用 C#来实现，如果使用 python 或其他语言，很难实现可以直接与服务通信客户端；进入移动互联网时代后，RPC 风格的服务很难在移动终端使用，而 RESTful 风格的服务，由于可以直接以 json或 xml 为载体承载数据，以 HTTP 方法为统一接
10、口完成数据操作，客户端的开发不依赖于服务实现的技术，移动终端也可以轻松使用服务，这也加剧了 REST 取代 RPC 成为 web service 的主导。RPC 与 RESTful 的区别如下面两个图所示：1.3 本真 REST 与 hybrid 风格通常开发者做服务相关的客户端开发时，使用的所谓 RESTful 服务，基本可分为本真 REST 和 hybrid 风格两类。本真 REST 即我上文阐述的RESTful 架构风格，具有上述的 4 个特点，是真正意义上的 RESTful风格；而 hybrid 风格，只是借鉴了 RESTful 的一些优点，具有一部分RESTful 的特点，但对外依然
11、宣称是 RESTful 风格的服务。（窃以为，正是由于 hybrid 风格服务混淆了 RESTful 的概念，才在 RESTful 架构风格提出了本真 REST 的概念，以为了划分界限 :P）hybrid 风格的最主流的用法是，使用 GET 方法获取资源，用 POST 方法实现资源的创建、修改和删除。hybrid 风格之所以存在，据我了解有两种来源：一种情况是因为，某些开发者并没有真正理解何为RESTful 架构风格，导致开发的服务貌合神离；而主流的原因是由于历史包袱 服务本来是 RPC 风格的，由于上文提到的 RPC 的劣势及 RESTful 的优势，开发者在 RPC 风格的服务上又包装了一层RESTful 的外壳，通常这层外壳只为获取资源服务，因此会按 RESTful风格实现 GET 方法，如果客户端提出一些简单的创建、修改或删除数据的需求，则通过 HTTP 协议中最常用的 POST 方法实现相应功能。因此，开发 RESTful 服务，如果没有历史包袱，不建议使用 hybrid风格。2. 认证机制由于 RESTful 风格的服务是无状态的，认证机制尤为重要。例如上文提到的员工工资，这应该是一个隐私资源，只有员工本人或其他少数有权限的人有资格看到，如果不通过权限认证机制对资源做一层限制，
