RESTful 架构风格概述
在当前互联网环境下，随着docker等技术的兴起，『微服务』的概念也越来越被大家接受并应用于实践，日益增多的web service逐渐统一于RESTful 架构风格，如果开发者对RESTful 架构风格不甚了解，则开发出的所谓RESTful
API总会貌合神离，不够规范。
本文是我对RESTful 架构风格的一些理解，和大家分享一下，不喜勿喷，欢迎讨论。
1.RESTful架构风格
RESTful架构风格最初由Roy T. Fielding（HTTP/1.1协议专家组负责人）在其2000年的博士学位论文中提出。HTTP就是该架构风格的一个典型应用。从其诞生之日开始，它就因其可扩展性和简单性受到越来越多的架构师和开发者们的青睐。一方面，随着云计算和移动计算的兴起，许多企业愿意在互联网上共享自己的数据、功能；另一方面，在企业中，RESTful API（也称RESTful Web服务）也逐渐超越SOAP成为实现SOA的重要手段之一。时至今日，RESTful架构风格已成为企业级服务的标配。 REST即Representational State Transfer的缩写，可译为"表现层状态转化”。REST最大的几个特点为：资源、统一接口、URI和无状态。
1.1 资源
所谓"资源"，它可以是一段文本、一张图片、一首歌曲、一种服务，总之就是一个具体的实在。资源总要通过某种载体反应其内容，文本可以用txt格式表现，也可以用HTML格式、XML格式表现，甚至可以采用二进制格式；图片可以用JPG格式表现，也可以用PNG格式表现；JSON是现在最常用的资源表示格式。
资源是以json(或其他Representation)为载体的、面向用户的一组数据集，资源对信息的表达倾向于概念模型中的数据：
- 资源总是以某种Representation为载体显示的，即序列化的信息
- 常用的Representation是json或者xml等
- Represntation 是REST架构的表现层
相对而言，数据（尤其是数据库）是一种更加抽象的、对计算机更高效和友好的数据表现形式，更多的存在于逻辑模型中。
1.2 统一接口
接口
RESTful架构风格规定，数据的元操作，即CRUD(create, read,update和delete,即数据的增删查改)操作，分别对应于HTTP方法：GET用来获取资源，POST用来新建资源（也可以用于更新资源），PUT用来更新资源，DELETE用来删除资源，这样就统一了数据操作的接口，仅通过HTTP方法，就可以完成对数据的所有增删查改工作，列出下图：
| 请求 | GET | POST | PUT | PATCH | DELETE |
|---|---|---|---|---|---|
| 意义 | SELECT | CREATE | UPDATE | UPDATE | DELETE |
| 解释 | 从服务器取出资源（一项或多项 | 在服务器新建一个资源 | 在服务器更新资源（客户端提供完整资源数据） | 在服务器更新资源（客户端提供需要修改的资源数据） | 从服务器删除资源 |
| 使用（本人项目） | 使用 | 使用 | 使用 | 暂不使用 | 使用 |
| 请求成功时 | 要返回对应的数据，及状态码200，即SUCCESS | ----- | 同GET | 同GET | ----- |
| 创建数据成功时 | ----- | 要返回创建的数据，及状态码201，即CREATED | ----- | ----- | ----- |
| 删除数据成功时 | ----- | ----- | ----- | ----- | 不返回数据，状态码要返回204，即NO CONTENT |
| 请求异常 | 校验请求数据时发现错误，要返回状态码 400，即BAD REQUEST | 同左侧 | 同左侧 | 同左侧 | 同左侧 |
| API 请求需要用户认证时 | 如果request中的认证信息不正确，要返回状态码 401，即NOT AUTHORIZED | 同左侧 | 同左侧 | 同左侧 | 同左侧 |
| API 请求需要验证用户权限时 | 如果当前用户无相应权限，要返回状态码 403，即FORBIDDEN | 同左侧 | 同左侧 | 同左侧 | 同左侧 |
关于Request 和 Response，不要忽略了http header中的Content-Type。以json为例，如果API要求客户端发送request时要传入json数据，则服务器端仅做好json数据的获取和解析即可，但如果服务端支持多种类型数据的传入，如同时支持json和form-data，则要根据客户端发送请求时header中的Content-Type，对不同类型是数据分别实现获取和解析；如果API响应客户端请求后，需要返回json数据，需要在header中添加Content-Type=application/json。
Serialization 和 Deserialization
Serialization 和 Deserialization即序列化和反序列化。RESTful API以规范统一的格式作为数据的载体，常用的格式为json或xml，以json格式为例，当客户端向服务器发请求时，或者服务器相应客户端的请求，向客户端返回数据时，都是传输json格式的文本，而在服务器内部，数据处理时基本不用json格式的字符串，而是native类型的数据，最典型的如类的实例，即对象（object），json仅为服务器和客户端通信时，在网络上传输的数据的格式，服务器和客户端内部，均存在将json转为native类型数据和将native类型数据转为json的需求，其中，将native类型数据转为json即为序列化，将json转为native类型数据即为反序列化。虽然某些开发语言，如Python，其原生数据类型list和dict能轻易实现序列化和反序列化，但对于复杂的API，内部实现时总会以对象作为数据的载体，因此，确保序列化和反序列化方法的实现，是开发RESTful API最重要的一步准备工作。
序列化和反序列化是RESTful API开发中的一项硬需求，所以几乎每一种常用的开发语言都会有一个或多个优秀的开源库，来实现序列化和反序列化，因此，我们在开发RESTful API时，没必要制造重复的轮子，选一个好用的库即可。如实体类实现 serializer 序列化。
当然了，RESTful API 是写给开发者来消费的，其命名和结构需要有意义。因此，在设计和编写URL时，要符合一定的规范。
在后续文章里会详细介绍在项目中的使用，敬请期待！
1.3 URI
每一个人都有自己的名字，有了名字，你才能找到别人，别人也才能找到你，这是社会中人与人通信的基本要求。因此，在任何一种通讯网络里，用户也都有其独特的用户标识，比如固定网络里的固定电话号码、移动网络里的移动电话号码等等，这样才能区分出不同的用户并进行通信。而URI（Uniform
Resource Identifier，统一资源标识符）就是在IMS网络中IMS用户的“名字”，也就是IMS用户的身份标识。
当然在实际应用中，每个资源至少有一个URI与之对应，URI即URL。
1.4 无状态
所谓无状态的，即所有的资源，都可以通过URI定位，而且这个定位与其他资源无关，也不会因为其他资源的变化而改变。有状态和无状态的区别。如查询员工的工资，如果查询工资是需要登录系统，进入查询工资的页面，执行相关操作后，获取工资的多少，则这种情况是有状态的，因为查询工资的每一步操作都依赖于前一步操作，只要前置操作不成功，后续操作就无法执行；如果输入一个url即可得到指定员工的工资，则这种情况是无状态的，因为获取工资不依赖于其他资源或状态，且这种情况下，员工工资是一个资源，由一个url与之对应，可以通过HTTP中的GET方法得到资源，是典型的RESTful风格。
1.5 ROA、SOA与REST
注意：在这里不谈RPC，RPC风格曾是Web Service的主流；RPC风格的服务，不仅可以用HTTP，还可以用TCP或其他通信协议。同样的RPC风格的服务，受开发服务采用语言的束缚比较大；进入移动互联网时代后，RPC风格的服务很难在移动终端使用，而RESTful风格的服务，由于可以直接以json或xml为载体承载数据，以HTTP方法为统一接口完成数据操作，客户端的开发不依赖于服务实现的技术，移动终端也可以轻松使用服务，REST终将取代RPC成为web service的主导。
ROA即Resource Oriented Architecture，RESTful架构风格的服务是围绕资源展开的，是典型的ROA架构（虽然“A”和“架构”存在重复，但说无妨），虽然ROA与SOA并不冲突，甚至把ROA看做SOA的一种也未尝不可，但由于RPC也是SOA，比较久远一点的论文、博客或图书也常把SOA与RPC混在一起讨论，因此，RESTful架构风格的服务通常被称之为ROA架构，很少提及SOA架构，以便更加显式的与RPC区分。
2.认证机制
由于RESTful风格的服务是无状态的，认证机制尤为重要。例如一个隐私资源，只有本人或其他少数有权限的用户有资格看到，不通过权限认证机制对资源做一层限制，那么所有资源都将以公开方式暴露出来，很不合理的，同样也很危险。
当然这样的问题肯定是需要解决的，解决权限问题可以想到：自定义权限认证，Shiro，SpringSecurity，SpringCloud-Aouth认证。
本系列只介绍博主在项目中的使用（SpringCloude-OAuth2.0的密码认证模式），权限认证中心案例正在抓紧整理上传，请持续关注！。
3.OAUTH
OAuth（开放授权）是一个开放的授权标准，允许用户让第三方应用访问该用户在某一web服务上存储的私密的资源（如照片，视频，联系人列表），而无需将用户名和密码提供给第三方应用。
OAuth允许用户提供一个令牌，而不是用户名和密码来访问他们存放在特定服务提供者的数据。每一个令牌授权一个特定的第三方系统（例如，视频编辑网站)在特定的时段（例如，接下来的2小时内）内访问特定的资源（例如仅仅是某一相册中的视频）。这样，OAuth让用户可以授权第三方网站访问他们存储在另外服务提供者的某些特定信息，而非所有内容。
正是由于OAUTH的严谨性和安全性，现在OAUTH已成为RESTful架构风格中最常用的认证机制，和RESTful架构风格一起，成为企业级服务的标配。
目前OAuth已经从OAuth1.0发展到OAuth2.0，但这二者并非平滑过渡升级，OAuth2.0在保证安全性的前提下大大减少了客户端开发的复杂性，因此，Gevin建议在实战应用中采用OAuth2.0认证机制。
现在网上关于OAuth的资料非常丰富，也有大量开源的第三方库实现了OAuth机制，不熟悉OAuth的同学从《OAuth官网》入手即可（想当初在博主实战编写项目并应用与单点登录权限认证中心的时候OAuth的资料是那么的少难啃的骨头啊）。
4. 总结
- SringCloud项目使用了OAUTH2.0的密码认证模式来进行编写权限认证中心。 REST + OAuth是RESTful
- 是微服务的标配。 我们需要设计合理的资源，需要各个团队的密切配合与合理分工。
- 当然最为重要的是一定要用正确的HTTP方法对数据发正确的请求。
- 博主编写的关于《微服务SpringCloud集群项目编写》的一系列文章，将会持续稳定的更新，感兴趣的小伙伴记得加关注哦！