**1**.Restful简介及特点
REST即Representational State Transfer的缩写，REST最大的几个特点为：资源、统一接口、URI和无状态。下面一一详解：
**(1)**. **资源**：所谓资源是指互联网上的一个实体，或者说是网络上的一个具体信息。他可以是一段文本、一张图片或是一个视频。资源总要通过某种载体反映其内容，文本可以用txt格式来表现，也可以用HTML格式；图片可以是png，也可以是JPG格式。JSON是现在最常用的资源表示格式。
结合开发实践，我们对资源和数据理解如下：
资源是以json或其他Representation（表现）为载体的、面向用户的一组数据集，资源对信息的表达倾向于概念模型中的数据：
（1）资源总是以某种Representation为载体现实的，即序列化的信息
（2）常用的Representation是json（推荐，轻量级）或xml（不推荐）等
（3）Representation是REST架构的表现层
相对而言，数据（尤其是数据库）是一种更加抽象的、对计算机更高效和更有好的数据表现形式，存在于逻辑模型中的资源和数据关系如下：
**(2)**. **统一接口**：RESTful架构风格规定，数据的元操作，即CRUD（数据的增删改查操作），对应HTTP中的POST、GET、PUT和DELETE，四个动作功能如下：
GET（SELECT）：从服务器取出资源；
POST（CREATE）：在服务器新建一个资源；
PUT（UPDATE）：在服务端更新资源（客户端提供完整资源数据）；
PATCH（UPDATE）：在服务端更新资源（客户端提供需要修改的资源数据），与PUT相比仅提供部分数据；
DELETE（DELETE）：从服务器删除资源。
**(3)**. **URI**：可以用一个URI指向资源，即每个URI都对应一个特定的资源。想要获取这个资源就去访问这个URI，因此URI就成了每一步资源的地质或识别符。
一般来说，每个资源都至少有一个URI与之对应，最典型的URI即URL。
**(4)**. **无状态**：所谓无状态，是指所有资源都可以通过URI定位，而且这个定位与其他资源无关，也不会因为其他资源的变化而改变。**个人是这样理解的，这个无状态我们可以参考HTTP无状态协议，用户的操作
遇上一步无关，每次只需传递必要数据就可以完成操作**。举例说明，我们查询自己的工资，首先需要登录公司系统，填写账号密码信息后，跳转到查询界面才能看到自己工资，这种情况我们称之为是有状态的，我们的每一步操作都依赖于前一步操作，只要前一步操作不成功，那后续操作就不能进行；那如果我们只需要输入一个URL就可以得到指定人员的工资，那我们将这种情况称之为无状态的，因为获取信息不依赖于其他资源或状态。而且这种情况下，我们可以将工资视作一个资源，由一个URL与之对应，可以通过HTTP中的GET方法得到资源，这是典型的RESTful风格。
日常一图顶千言，区分有状态和无状态：
**2**.ROA、SOA、REST和RPC
ROA即Resource Oriented Architecture（面向资源架构），RESTful架构风格的服务是围绕资源来展开的，是典型的ROA。虽然ROA与SOA并不冲突，甚至把ROA看做SOA的一种也说的通，但由于RPC也是SOA，早期的文档常常把SOA和RPC混在一起讨论，因此RESTful架构风格的服务通常被称之为ROA架构，为了更好地与RPC区分。
RPC风格曾经是Web Service 的主流，最初是基于XML-RPC协议，RPC风格的服务不仅可以使用HTTP协议，也可以用TCP/IP或其他通讯协议。但RPC风格的服务收开发服务采用的语言束缚较大，尤其是进入移动互联网时代后，RPC风格的服务很难再移动终端使用。而RESTful风格的服务由于可以使用json或xml为载体承载数据，以HTTP方法未同意借款完成数据操作，客户端的开发不依赖于服务实现的技术，移动终端也可以很方便地使用服务，这也加剧了RESTful取代RPC称为WEBservice的主导。
下图为RPC风格的服务与RESTful风格的服务对比：
**3**.本真REST和hybrid风格
通常开发者做服务相关的客户端开发时，使用的所谓RESTful服务，基本可以分为本真REST和hybrid两种。
具有我们第一个知识点里说的四个特点，是真正意义上的RESTful风格；而hybrid风格只是借鉴了RESTful风格的一些特点，但对外宣称依然是RESTful风格的服务。
hybrid风格的主流用法是，使用GET方法获取资源，用POST方法实现资源的创建、修改和删除，hybrid风格之所以存在，据大神总结来源有二：一种情况是因为，某些开啊这并没有真正理解何为RESTful架构风格，导致开发的服务似是而非；另一种情况是因为历史包袱，初期开发本来是RPC风格，半路改为RESTful风格，这种情况下开发者会选择在RPC风格的服务外包一层RESTful风格的外壳，通常这层外壳只为回去资源服务，因此会按RESTful风格实现GET方法，如果客户端提出以下简单的创建修改删除数据需求，则会通过HTTP协议中的最常用POST实现相应功能。
**4**.认证机制
由于RESTful风格的服务是无状态的，认证机制尤为重要。比如我们上文提到的查询工资，仅允许当事人与更高权限的用户进行查看，如果不通过权限认证机制对自愿做一层限制，那么所有的资源都是公开的，对于用户来说就变得非常不保险。
认证机制解决的问题是：确定访问资源的用户是谁；权限机制解决的问题是：确定用户是否被许可进行增删改查操作。权限机制通常与服务的业务逻辑绑定，因此权限机制需要在每个系统内部制定，而认证机制则是通用的，常用的认证机制由**session auth**（即通过用户密码登录）、**basic auth**、**token auth**和**OAuth**。服务开发中常用的认证机制为后三种。下面我们来详细介绍这三种：
**（1）****basic auth**：Basic Auth是配合RESTful API 使用的最简单的认证方式，只需提供用户名密码即可，但由于有把用户名密码暴露给第三方客户端的风险，在生产环境下被使用的越来越少。因此，在开发对外开放的RESTful API时，尽量避免采用Basic Auth，但是可以在开发环境下使用。
**（2）****token auth**：Token Auth并不常用，它与Basic Auth的区别是，不将用户名和密码发送给服务器做用户认证，而是向服务器发送一个事先在服务器端生成的token来做认证。因此Token Auth要求服务器端要具备一套完整的Token创建和管理机制，该机制的实现会增加大量且非必须的服务器端开发工作，也不见得这套机制足够安全和通用，因此Token Auth用的并不多。
**（3）****OAuth**：OAuth（开放授权）是一个开放的授权标准，允许用户让第三方应用访问该用户在某一web服务上存储的私密的资源（如照片，视频，联系人列表），而无需将用户名和密码提供给第三方应用。
OAuth允许用户提供一个令牌，而不是用户名和密码来访问他们存放在特定服务提供者的数据。每一个令牌授权一个特定的第三方系统（例如，视频编辑网站)在特定的时段（例如，接下来的2小时内）内访问特定的资源（例如仅仅是某一相册中的视频）。这样，OAuth让用户可以授权第三方网站访问他们存储在另外服务提供者的某些特定信息，而非所有内容。
正是由于OAUTH的严谨性和安全性，现在OAUTH已成为RESTful架构风格中最常用的认证机制，和RESTful架构风格一起，成为企业级服务的标配。
目前OAuth已经从OAuth1.0发展到OAuth2.0，但这二者并非平滑过渡升级，OAuth2.0在保证安全性的前提下大大减少了客户端开发的复杂性，因此，Gevin建议在实战应用中采用OAuth2.0认证机制。
**总结**：
**本真REST + OAuth是RESTful 是微服务的标配**
**Basic Auth只在开发环境中使用**
**设计合理的资源**
**用正确的HTTP方法对数据发正确的请求**
有疑问加站长微信联系（非本文作者））
