Interface, Powerful, Simple, Interactive, Cross-Platform
The following briefly describes the two major interface ideas
A REST:
REST is an architectural style whose core is resource-oriented. REST is specially designed and developed for network applications to reduce the complexity of development and improve the scalability of the system.
REST proposes design concepts and principles as follows:
1. Everything on the network can be abstracted into resources
2. Each resource has a unique resource identifier, and operations on resources will not change these
identifiers3 .All operations are stateless
REST to simplify development, and its architecture follows the CRUD principle, which tells us that only four behaviors are required for resources (including network resources): create, acquire, update and delete to complete related operations and deal with. You can identify and locate resources by a Universal Resource Identifier (URI), and the actions to be performed on those resources are defined by the HTTP specification. Its core operations are only GET, PUT, POST, DELETE .
Since REST enforces that all operations must be stateless, there is no context constraint. If distributed, the cluster does not need to consider the context and session retention. Greatly improve the scalability of the system .
二 SOAP
SOAP tends to be activity-oriented and has strict specifications and standards, including security, transactions and other aspects.
SOAP emphasizes the separation of operation methods and operation objects, which are defined by WSDL file specification and XSD file respectively.
REST emphasizes resource-oriented, as long as the objects we want to operate can be abstracted as resources, the REST architectural style can be used.
How to be sure to use REST:
If it is just a simple CRUD business operation, it is easier to abstract resources.
However, it is not a simple thing to abstract resources for complex business activities, such as verifying user level, transfer, transaction processing, etc.
How to determine the use of SOAP:
If there are strict specifications and standard definition requirements, and you need to guide the integration and development of multiple business systems in the early stage,
SOAP is more suitable because the SOAP style has a clear standard definition.
We can strictly define the relevant interface methods and interface transfer data before starting and implementing.
In one sentence:
Simple data manipulation, no transaction processing, and simple REST architecture style for development and invocation.
Furthermore: The core of
REST is url and resource-oriented, and url replaces the original complex operation method.
REST allows us to design systems through urls, just as test-driven development uses test cases to design class interfaces.
Anything that can be abstracted as a resource can use RESTful urls .
REST key:
The key to using REST is how to abstract resources. The more precise the abstraction, the better the application of REST.
———————————————————————————————————————
Three REST Ideas
1. Resource-Oriented Interface Design
All interface designs are designed for resources (including operations are also a resource).
The design of URI also reflects the positioning design of resources.
2．抽象操作为基础的CRUD
Http中的get,put,post,delete分别对应了read,update,create,delete四种操作
如果仅仅是作为对于资源的操作，抽象成为这四种已经足够了，但是对于复杂的业务接口，未必能够满足。
完全按照REST的思想来设计，那么适用的环境将会有限制，而非放之四海皆准的。
3．Http是应用协议而非传输协议
部分认为：REST的理念设计，其实是作了一套私有的SOAP协议，因此称之为REST风格的自定义SOAP协议。
4．无状态，自包含
接口设计都需做到这点，不仅仅是REST，也是作为可扩展和高效性的最基本的保证，SOAP也类似。
四 SOAP Webservice和RESTful Webservice的比较
1.成熟度(总的来说SOAP在成熟度上优于REST)
SOAP对于异构环境服务发布和调用，以及厂商的支持都已经达到了较为成熟的情况。
REST国外很多大网站都发布了自己的开发API，很多都提供了SOAP和REST两种Web Service，
但是由于REST只是一种基于Http协议实现资源操作的思想，因此各个网站的REST实现都自有一套。
REST实现的各种协议仅仅只能算是私有协议，当然需要遵循REST的思想。
2.效率和易用性(REST更胜一筹)
SOAP协议对于消息体和消息头都有定义，同时消息头的可扩展性为各种互联网的标准提供了扩展的基础，
WS-*系列就是较为成功的规范。但是也由于SOAP由于各种需求不断扩充其本身协议的内容，导致在SOAP
处理方面的性能有所下降。同时在易用性方面以及学习成本上也有所增加。
REST被人们的重视，其实很大一方面也是因为其高效以及简洁易用的特性。
这种高效一方面源于其面向资源接口设计以及操作抽象简化了开发者的不良设计，
同时也最大限度的利用了Http最初的应用协议设计理念。
同时，REST很好的融合当前Web2.0的很多前端技术来提高开发效率。
例如:很多大型网站开放的REST风格的API都会有多种返回形式（XML,JSON,RSS,ATOM）等形式。
3.安全性
SOAP在安全方面使用XML-Security和XML-Signature两个规范组成了WS-Security来实现安全控制的，
当前已经得到了各个厂商的支持，.net ，php ，java 都已经对其有了很好的支持。
REST 开放REST风格API的网站主要分成两种:
一种是自定义了安全信息封装在消息中，
另外一种就是靠硬件SSL来保障,这只能够保证点到点的安全，如果是需要多点传输的话SSL就无能为力了。
安全这块其实也是一个很大的问题。
五 应用设计与改造
我们的系统要么就是已经有了那些需要被发布出去的服务，要么就是刚刚设计好的服务，但是开发人员的传统设计思想让REST的形式被接受还需要一点时间。同时在资源型数据服务接口设计上来说按照REST的思想来设计相对来说要容易一些，而对于一些复杂的服务接口来说，可能强要去按照REST的风格来设计会有些牵强。这一点其实可以看看各大网站的接口就可以知道，很多网站还要传入function的名称作为参数，这就明显已经违背了REST本身的设计思路。而SOAP本身就是面向RPC来设计的，开发人员十分容易接受，所以不存在什么适应的过程。总的来说，其实还是一个老观念，适合的才是最好的
技术没有好坏，只有是不是合适，一种好的技术和思想被误用了，那么就会得到反效果。REST和SOAP各自都有自己的优点，同时如果在一些场景下如果去改造REST，其实就会走向SOAP（例如安全）。
REST对于资源型服务接口来说很合适，同时特别适合对于效率要求很高，但是对于安全要求不高的场景。而SOAP的成熟性可以给需要提供给多开发语言的，对于安全性要求较高的接口设计带来便利。所以我觉得纯粹说什么设计模式将会占据主导地位没有什么意义，关键还是看应用场景。
同时很重要一点就是不要扭曲了REST现在很多网站都跟风去开发REST风格的接口，其实都是在学其形，不知其心，最后弄得不伦不类，性能上不去，安全又保证不了，徒有一个看似象摸象样的皮囊。