A, Soap and Rest definition
SOAP (Simple Object Access Protocol Simple Object Access Protocol), the Web Service for remote call and return the package data into machine-readable format, in fact SOAP XML data format to describe the remote procedure call, parameters, The return value and error messages, and so on. In fact, SOAP RPC was first directed to a solution of decision program, very lightweight, but as the application protocol message can be delivered (Http, SMTP, etc.) based on a variety of transport protocols. But with the wide range of applications as SOAP WebService, continue to add additional content, so that developers now feel very heavy SOAP, use the threshold, and with the growth in demand, and shall not increase the protocol to support security, which makes SOAP become unusually large, simple departure from the original intention. In the subsequent development process SOAP, WS- * series of agreements to develop and increase the maturity of SOAP, but also to increase the burden on SOAP. SOAP is often referred to as "web services", which is a misnomer. SOAP and web basically can not speak. REST provides real-based URL and HTTP "web services".
REST (Representational State Transfort representational state transfer) should be formally expressed to achieve the transition state for the client through application resource, in this point of the system can be viewed as a virtual state machine. REST in accordance with the principles of software design, architecture, commonly referred to as "REST-style" (RESTful), Dr. RT Fielding aside the theory papers in obscure not say, REST should satisfy such characteristics:
1) The client and server architecture;
2) having a stateless protocol connection;
3) to take advantage of Cache mechanism to enhance performance;
4) hierarchical system;
5) code on demand.
REST is just an architectural style, rather than protocol or standard. But the impact of this new style to the existing SOAP Web Service represented result is revolutionary because it is resource-oriented, and even services are abstracted into resources, and HTTP because it closely, and the server is stateless. Using server-side J2EE, client using JSP, Flex, JavaFX, AIR and other Servlet can call directly, other implementation techniques basically can not be called directly, but whether it is the kind of client for SOAP-based Web services or RESTful Web-based service Services are supported, such as the AJAX XMLHttpRequest, Flex HTTPService the like.
二、Soap VS Rest
① in the maturity of
For soap, as well as support for vendor heterogeneous environment service publishing and calls have reached a certain maturity, different platforms, programming languages to interact with web service can better communicate through soap;
rest is an idea based on http protocol resources operations, but no definitive agreement similar to soap as a norm, implemented various protocols rest can only be considered a proprietary protocol to follow rest thought, so not too many constraints in the details .
superior soap rest on maturity.
② efficiency and ease of use
soap protocol for message bodies and headers are defined, and scalability various Internet message header standard provides the basis for the extension, WS_ * series is more successful specification. But the soap due to various demand continued to expand the content of its own protocol, resulting in the soap processing performance has declined, while the cost in terms of ease of use and learning has improved;
rest are valued by the people, on the one hand is great because of its highly efficient and simple to use features, which on the one hand due to its efficient use of resources and operations-oriented interface design abstraction simplifies the developer's bad design, but also to maximize the the initial application of the http protocol design, while, rest and a very attractive developer is able to blend well a lot of front-end technology to improve the efficiency of the current web2.0, for example, many large open API site will have a rest-style a variety of forms returned, in addition to traditional XML as the bearer, as well as json, rss, atom and other forms, which for many front-end developers can well mashup of information resources.
In terms of efficiency and ease of use, rest better.
③ in the application design and renovation
For the rest very appropriate resources for service-oriented interfaces, and is particularly suitable for demanding efficiency, but safety is not high for a scene, and the maturity of soap can bring convenience to the security interface design requirements and high, so I think pure say what design patterns will dominate does not make sense, the key is to fit scenarios.
三、Why Rest？
- REST uses the standard HTTP So what it does is more simple. Create a client, development API, documentation easier to understand, and not a thing to do with it than SOAP REST easier / better.
- REST allows many different data formats and SOAP only supports XML. Although this seems to REST adds complexity because you need to handle multiple formats, but in my experience, this actually has many advantages. JSON often more amenable to carry data and faster to resolve. Because of its support for JSON, REST allows us to better support the browser client.
- REST with better performance and scalability. REST can be cached read, and read SOAP-based can not be cached.
For a library online inquiry management system, for example, the service provider must provide an internal identifier of each book is then possible to define a listBooks operation to return a series of books, a getBook operation to return the specified books, a createBook operation new books added to the database, a deleteBook operation to remove obsolete books, each operation has its own parameters, especially books with internal identifier to identify the operation. This design is faulted, wherein deleteBook operation should be sent with the POST method, the HTTP protocol but in fact a more logical and DELETE methods available. It is designed so that REST, REST for each resource (here Books) assigned a unique URI, and use of four methods GET HTTP, POST, PUT, DELETE visually represent access, create, update, and delete books. While the collection of books also and single this book different resources, if / books to represent the list of books / books / ID to represent identified as books ID, then on / books of GET operations on behalf returns the entire list of books on / dELETE operations on behalf of books / ID to delete the specified books, and so on.
四、Why Soap？
①web services secure
SOAP REST like not only as support SSL, but also support a lot more enterprise-level security features of the WS-Security (WS = web services ). Therefore, it can provide authenticated intermediary, not just the end to end authentication (SSL). Furthermore, SOAP also provides a standard privacy and data integrity of a data implemented. Call it an "enterprise" is not it safer, it simply provides a typical Internet service does not require several security tools only, in fact, these tools only in a very few "enterprise" in order to send the scene use.
②web services atomicity
if the service requires ACID transactions, then you will need a SOAP. Although REST also supports transactions, but it is not and does not have the integrity of ACID. Fortunately ACID transactions to the Internet is almost no sense. REST is limited to HTTP, HTTP itself can not provide two-phase commit distributed transactions resource, but SOAP can. Internet applications generally do not require this level of reliability of other affairs, enterprise-class applications is sometimes needed. (ACID, an abbreviation for the four basic elements of proper execution of database transactions include: atomicity (Atomicity), consistency (Consistency), isolation (Isolation), persistent (Durability))
③web services message reliability
REST message does not have a standard system, it is desired by the client to retry failed communication process. SOAP includes a built-in success / retry logic and to provide reliable end to end by a SOAP intermediary.
For example, if I go to write a connection to the iPhone app my bank so of course I need to use SOAP. Above three features are essential banking firm. For example, if I transfer funds from one account to another account, I need to make sure it's complete. If the first transfer is successful, but fails to respond, this time REST retry will be disastrous.
Understand, in SoapUI tool, If the interface is transmitting data in response to xml, on the use of New SOAP Project; all others use New REST Project, such an interface is returned JSON format.
Reference: https://www.soapui.org/learn/tutorials/web-service-example-projects.html