一方面，随着云计算和移动计算的兴起，许多企业愿意在互联网上共享自己的数据、功能；另一方面，在企业中，RESTful API（也称RESTful Web服务）也逐渐超越SOAP成为实现SOA的重要手段之一。时至今日，RESTful架构风格已成为企业级服务的标配。
SOA
全称：Service Oriented Architecture，SOA架构用于异构系统的协作，因此需要一种跨操作系统、跨语言的通用的消息交换格式。SOAP和REST都是基于文本的消息体，相比二进制消息而言具有跨平台的优势，因此被选作SOA接口的常用实现方法。
正因为SOA架构实现不依赖于技术，因此能够被各种不同的技术实现。例如：SOAP, RPC，REST
特点
REST即Representational State Transfer的缩写，可译为"表现层状态转化”。REST最大的几个特点为：资源、统一接口、URI和无状态。
REST并不是一种协议，只是一种设计规范，该设计规范要求程序遵守HTTP协议最初设计的初衷，使用HTTP的GET/PUT/DELTET/POST对资源进行操作，REST接口是以URI资源为基础，对资源进行CRUD操作的接口。
那么SOAP是什么呢？SOAP：一种简单的基于 XML 的协议，它使应用程序通过 HTTP 来交换信息。
资源
JSON是现在最常用的资源表示格式。
资源是以json(或其他Representation)为载体的、面向用户的一组数据集，资源对信息的表达倾向于概念模型中的数据：
- 资源总是以某种Representation为载体显示的，即序列化的信息
- 常用的Representation是json(推荐)或者xml（不推荐）等
- Represntation 是REST架构的表现层
统一接口
RESTful架构风格规定，数据的元操作，即CRUD(create, read, update和delete,即数据的增删查改)操作，分别对应于HTTP方法：GET用来获取资源，POST用来新建资源（也可以用于更新资源），PUT用来更新资源，DELETE用来删除资源，这样就统一了数据操作的接口，仅通过HTTP方法，就可以完成对数据的所有增删查改工作。
- GET（SELECT）：从服务器取出资源（一项或多项）。
- POST（CREATE）：在服务器新建一个资源。
- PUT（UPDATE）：在服务器更新资源（客户端提供完整资源数据）。
- PATCH（UPDATE）：在服务器更新资源（客户端提供需要修改的资源数据）。
- DELETE（DELETE）：从服务器删除资源。
URI
可以用一个URI（统一资源定位符）指向资源，即每个URI都对应一个特定的资源。要获取这个资源，访问它的URI就可以，因此URI就成了每一个资源的地址或识别符。一般的，每个资源至少有一个URI与之对应，最典型的URI即URL。
URI和URL的区别：URL是URI的子集，两者均说明的资源是什么，但是URL还说明了如何得到资源。
无状态
所谓无状态的，即所有的资源，都可以通过URI定位，而且这个定位与其他资源无关，也不会因为其他资源的变化而改变。有状态和无状态的区别，举个简单的例子说明一下。如查询员工的工资，如果查询工资是需要登录系统，进入查询工资的页面，执行相关操作后，获取工资的多少，则这种情况是有状态的，因为查询工资的每一步操作都依赖于前一步操作，只要前置操作不成功，后续操作就无法执行；如果输入一个url即可得到指定员工的工资，则这种情况是无状态的，因为获取工资不依赖于其他资源或状态，且这种情况下，员工工资是一个资源，由一个url与之对应，可以通过HTTP中的GET方法得到资源，这是典型的RESTful风格。
有状态：后面的每一个状态都依赖于前一个状态。
无状态：对每个请求的资源，都不依赖于其他资源或其他请求，每个资源都是可寻址的，都有至少一个url能对其定位。无状态更加方便客户端使用服务器的资源或服务。
RPC和REST区别
图片来源于网络，但是真心没理解。等待时间让我理解了。
本真REST与hybrid风格
通常开发者做服务相关的客户端开发时，使用的所谓RESTful服务，基本可分为本真REST和hybrid风格两类。本真REST具有上述的4个特点，是真正意义上的RESTful风格；而hybrid风格，只是借鉴了RESTful的一些优点，具有一部分RESTful的特点，但对外依然宣称是RESTful风格的服务。
hybrid风格的最主流的用法是，使用GET方法获取资源，用POST方法实现资源的创建、修改和删除。hybrid风格之所以存在，据我了解有两种来源：一种情况是因为，开发者并没有真正理解何为RESTful架构风格，导致开发的服务貌合神离；而主流的原因是由于历史包袱 —— 服务本来是RPC风格的，由于上文提到的RPC的劣势及RESTful的优势，开发者在RPC风格的服务上又包装了一层RESTful的外壳，通常这层外壳只为获取资源服务，因此会按RESTful风格实现GET方法，如果客户端提出一些简单的创建、修改或删除数据的需求，则通过HTTP协议中最常用的POST方法实现相应功能。
因此，开发RESTful 服务，如果没有历史包袱，不建议使用hybrid风格。
认证机制
由于REST是无状态的，所以对于敏感信息，需要通过认证和权限对request进行限制，认证信息放request的head中，而不是body中，权限的逻辑在REST后台实现。
认证机制解决的问题是，确定访问资源的用户是谁；权限机制解决的问题是，确定用户是否被许可使用、修改、删除或创建资源。权限机制通常与服务的业务逻辑绑定，因此权限机制需要在每个系统内部定制，而认证机制基本上是通用的，常用的认证机制包括 session auth(即通过用户名密码登录)，basic auth，token auth和OAuth，服务开发中常用的认证机制为后三者。
Basic auth: 只需提供用户名密码即可，但由于有把用户名密码暴露给第三方客户端的风险，在生产环境下被使用的越来越少。因此，在开发对外开放的RESTful API时，尽量避免采用Basic Auth。
Token auth: Token Auth并不常用，它与Basic Auth的区别是，不将用户名和密码发送给服务器做用户认证，而是向服务器发送一个事先在服务器端生成的token来做认证。因此Token Auth要求服务器端要具备一套完整的Token创建和管理机制，该机制的实现会增加大量且非必须的服务器端开发工作，也不见得这套机制足够安全和通用，因此Token Auth用的并不多。
OAuth:【如果要使用，可以多多了解】
- 本真REST + OAuth是RESTful 是微服务的标配
- Basic Auth只在开发环境中使用