RESTAPI（RESTful）基于微服务SpringCl

本文已参与掘金创作者训练营第三期，详情查看：掘力计划｜创作者训练营第三期正在进行，「写」出个人影响力。

📖摘要

我的征途——是星程大海！

有多少路我将行走，有多少山峰我将为了寻找自己而去征服，有多少次我将失败，有多少次我将重新开始，而这一切是否有意义，我会耐心等待，我为自己准备，那通向我梦想和希望的旅程。不要燃尽自己，我的星辰，请等我。

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)为载体的、面向用户的一组数据集，资源对信息的表达倾向于概念模型中的数据：

1. 资源总是以某种Representation为载体显示的，即序列化的信息
2. 常用的Representation是json或者xml等
3. Represntation 是REST架构的表现层

相对而言，数据（尤其是数据库）是一种更加抽象的、对计算机更高效和友好的数据表现形式，更多的存在于逻辑模型中。

1.2 统一接口

接口

RESTful架构风格规定，数据的元操作，即CRUD(create, read,update和delete,即数据的增删查改)操作，分别对应于HTTP方法：GET用来获取资源，POST用来新建资源（也可以用于更新资源），PUT用来更新资源，DELETE用来删除资源，这样就统一了数据操作的接口，仅通过HTTP方法，就可以完成对数据的所有增删查改工作，列出下图：

关于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的资料是那么的少难啃的骨头啊）。

🎉最后

• SringCloud 项目使用了 OAUTH2.0 的密码认证模式来进行编写权限认证中心。 REST + OAuth 是 RESTful

• 是微服务的标配。 我们需要设计合理的资源，需要各个团队的密切配合与合理分工。

• 当然最为重要的是一定要用正确的HTTP方法对数据发正确的请求。

• 更多参考精彩博文请看这里：陈永佳的博客

• 喜欢博主的小伙伴可以加个关注、点个赞哦，持续更新嘿嘿！