SOAP 过于复杂，设计是面向动作的，往往因为架构问题导致并发量上不去。
RESTful 是一种架构模式，主要面向资源，提供无状态服务，有利于横向扩展应对高并发。
传输协议问题
传输协议问题—基于 HTTP。
对于 SOAP，创建一个订单，用 POST 动作，在 XML 中写明动作是 CreateOrder。其实可以简化，直接用 POST 动作，然后在 XML 中放一个订单 ID 即可。
于是 SOAP 可简化为
POST /purchaseOrder HTTP/1.1
Host: www.geektime.com
Content-Type: application/xml; charset=utf-8
Content-Length: nnn
<?xml version="1.0"?>
<order>
<date>2018-07-01</date>
<className> 趣谈网络协议 </className>
<Author> 刘超 </Author>
<price>68</price>
</order>
而 XML 格式也可改成另一种简单的文本化的对象表示格式 JSON。
POST /purchaseOrder HTTP/1.1
Host: www.geektime.com
Content-Type: application/json; charset=utf-8
Content-Length: nnn
{
"order": {
"date": "2018-07-01",
"className": " 趣谈网络协议 ",
"Author": " 刘超 ",
"price": "68"
}
}
协议约定问题
协议约定问题—基于JSON。
RESTful，是一种架构风格，全称 Representational State Transful，表述性状态转移。
客户端和服务端谁来维护状态？状态是指对某个数据当前处理到什么程度了。
很多 SOAP 接口是按照服务端维护状态模式设计的，不适用于有太多客户端同时连接的场景。
解决：服务端只记录资源的状态，由客户端维护会话的状态。比如，客户端想访问下一页，先查看自己当前访问到哪一页，是 100~110 页，然后告诉服务端想访问 110~120 页。
对于服务端，只有资源的状态改变了，客户端才调用 POST、PUT、DELETE 方法；如果资源状态没变，只是客户端的状态变了，对于服务端而言都是 GET。虽然只改进了 GET，但带来很大进步，因为对于互联网应用，大多是读多写少的，这也为缓存提供了方便。
对于 API 的设计，慢慢变成以资源为核心，而非以过程为核心。这种 API 的设计需实现幂等，因为网络不稳定，经常出错，需要重试，但同一个调用，多次调用的结果应该一样。如 cd a，不能因为重试了 3 次，就变成 cd a/a/a。
RESTful API 和 SOAP API 都可以将架构实现成无状态，面向资源的、幂等的、横向扩展的、可缓存的。但 SOAP 的 XML 正文中，可以放任何动作，如 ADD、MINUS 等，而RESTful 正文里的 JSON 基本描述的就是资源的状态，没办法描述动作，发出的动作只有 CRUD，即 POST、GET、PUT、DELETE，是对于状态的改变，从接口的角度提供了保障。
服务发现问题
有个著名的基于 RESTful API 的跨系统调用框架叫 Spring Cloud，在 Spring Cloud 中有一个组件叫 Eureka，是用来实现注册中心，负责维护注册的服务列表。
服务分服务提供方，它向 Eureka 做服务注册、续约和下线等操作，注册的数据包括服务名、机器 IP、端口号、域名等。为实现负责均衡和容错，服务提供方可以注册多个。
另外一方是服务消费方，向 Eureka 获取服务提供方的注册信息。消费方调用服务时，采用 RESTful 方式。Spring Cloud 提供要给 RestTemplate 工具，将请求对象转换为 JSON，并发起 Rest 调用，RestTemplate 的调用分 POST、PUT、GET、DELETE，结果返回时，根据返回的 JSON 解析成对象。