There are a lot of people asked us in the end should be the most popular choice in the design of the underlying service architecture RestFul time chose veteran webService it? Today I will elaborate these two concepts do something, in the end choose what is reasonable under the circumstances.
First of all you need to know: REST is an architectural style, its core is resource-oriented; and webService underlying SOAP protocol, the core is mainly oriented activities;
Related concepts:
SOAP
What is SOAP, I think Needless to say, google an eyeful. In fact, SOAP RPC was first for a solution, Simple Object Access Protocol, is 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, we continue to add additional content, so that now developers think SOAP heavy use threshold is high. 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.
REST
REST is not really what the agreement is not a standard, but the interpretation made Http protocol is designed, in the Http protocol is widely used today, it is more and more as a transport protocol, instead of the original designers application protocol under consideration. WebService SOAP type is the best example, the SOAP message is entirely Http protocol as a message bearer, that for various parameters (e.g., coding, error code, etc.) are disregarded Http protocol. In fact, most lightweight application protocol is Http protocol. Http protocol abstract get, post, put, delete database like the most basic CRUD, and a variety of resources on the Internet is like the records in the database, for the operation of various resources always the last to become this abstract four basic operations, the rules are defined after locating resources, resources for operation via standard Http agreement can be achieved, developers will benefit from this lightweight protocol.
REST specifically for the network application design and develop ways to reduce the complexity of development and improve the scalability of the system. REST proposed design concepts and guidelines for:
all the things on the 1. Network can be abstracted as resources (Resource)
2. Each resource has a unique resource identifiers (resource identifier), the operation of the resources will not change these logos
3 All operations are stateless
REST simplifies the development, its architecture follows the CRUD principle, the principle tells us to resources (including network resources) needed only four acts: create, retrieve, update, and delete operations can be completed and the related processing. We can be identified by the uniform resource identifier (Universal Resource Identifier, URI) and locating resources, operations and perform on these resources are defined by the HTTP specification. Its core operations only GET, PUT, POST, DELETE. Because REST mandatory for all operations must be stateless, which is not binding context, if you do a distributed, cluster and do not need to consider the context of the conversation on hold. Greatly improve system scalability.
SOAP webService strict norms and standards, including all aspects of content security affairs, stressed that while SOAP separate operating methods and objects, there WSDL file specification and XSD files are its definition.
If this sense, we need to consider whether to use REST resource itself abstract and difficult to identify whether, if itself is simple CRUD similar business operations, it is easier to abstract resources, and for complex business activities abstract resources It is not a simple matter. For example, check the user level, transfer, transaction processing, these are often not easy to simply as abstract resources.
Second, if there are strict norms and standards define requirements, and pre-normative standards need guidance multiple business systems integration and development time, SOAP style due to a clear specification standard definition is clearly advantageous. We can strictly define the relevant interface methods and the interface to transfer data and to achieve before you start. Under (in many cases is for compatibility with previous projects and call the front desk could not move the code logic of the premise, change the underlying application, generally need to use webService model development, because the old code has a clear method definitions and parameters type, number Affirming etc.)
simple data manipulation, no transaction processing, development, and these calls are simple to use REST architectural style advantage. For more complex service-oriented activities, if we use REST, most of the time is still thinking through traditional activities for the conversion tool and then converted REST services, this use does not make sense.