JAVA revision: The difference between WebService and restful __java

Transfer from Network)

Rest is an architectural style whose core is resource-oriented, and rest is designed and developed specifically for network applications to reduce the complexity of development and improve the scalability of the system. Rest presents design concepts and guidelines for:

1. All things on the web can be abstracted as resources (Resource)
2. Each resource has a unique resource identifier (resource identifier), and the operations on the resource do not change these identities
3. All operations are state-free.


Rest simplifies development, and its architecture follows the CRUD principle, which tells us that only four behaviors are required for resources (including network resources): Create, get, update, and delete to complete the relevant operations and processing. You can identify and locate resources through a Uniform Resource identifier (Universal Resource Identifier,uri), and actions taken against those resources are defined through the HTTP specification. Its core operation is only get,put,post,delete.


Because rest enforces that all operations must be stateless, there is no context constraint and, if distributed, the cluster does not need to consider context and session retention issues. Greatly improve the scalability of the system.


For the choice of soap webservice and restful webservice, the first thing to understand is that soap is biased toward activity-oriented, with strict specifications and standards, including security, transactions, and so on, while soap emphasizes the separation of operation methods and manipulation objects, The WSDL file specification and XSD file are defined separately. While rest emphasizes resource-oriented, the rest architecture style can be used as long as the objects we want to manipulate can be abstracted as resources.


REST FUL application problems
Whether or not to use rest requires consideration of the abstraction and identification of the resource itself, and if it is simply a business operation that is similar to adding or deleting, it is easier to abstract resources, and abstract resources for complex business activities is not a simple matter. For example, check user rating, transfer, transaction processing, etc., these are often not easy to simply abstract as resources.


Secondly, if there is a strict specification and standard definition requirements, and the pre-standard standards need to guide the integration and development of multiple business systems, SOAP style because of a clear definition of standard standards are obvious advantages. We can strictly define the relevant interface methods and interfaces before the start and implementation of the data transfer.


Simple data manipulation, no transaction processing, development and invocation simplicity are the advantages of using the rest architecture style. For more complex, activity-oriented services, if we still use rest, many times it is still the traditional idea of activity-oriented thinking through the conversion tool to convert to rest services, this way of use is meaningless.


Efficiency and ease of use
The SOAP protocol is defined for both the message body and the message headers, while the scalability of the message headers provides an extended basis for various Internet standards, and the Ws-* series is a more successful specification. But also because SOAP expands the content of its own protocol as a result of various requirements, the performance in SOAP processing has decreased. At the same time, the ease of use and the cost of learning also increased.


Rest is valued by people, but it is also because of its efficiency and simplicity and ease of use. This efficiency stems from its resource-oriented interface design and Operation Abstraction simplifies the developer's bad design, but also maximizes the use of HTTP Initial application protocol design concept. At the same time, it seems to me that rest has a very attractive developer who is able to integrate many of the front-end technologies of the current Web2.0 to improve development efficiency. For example, many large Web sites open to the rest-style API will have a variety of return forms, in addition to traditional XML as data bearer, as well as (Json,rss,atom) and other forms, which for many web site front-end developers can be very good mashup of various resource information


Security
The technology is not good or bad, only is not suitable, a kind of fine technology and thought is misused, then will get the counter effect. Rest and soap each have their own advantages, and if you change rest in some scenarios, you actually move to soap (for example, security).


Rest is appropriate for resource-oriented service interfaces, and is particularly suited for scenarios where efficiency requirements are high, but security requirements are not high. And the maturity of soap can give the need to provide for the development of languages, for the security requirements of the interface design more convenient. So I think it doesn't make sense to say exactly what design patterns will dominate, and the key is to look at the application scenario.


At the same time, it's important not to twist the rest. Now many websites have followed the development of rest-style interface, in fact, are learning its shape, do not know its heart, finally made nondescript, performance does not go, security and guarantee not.


Maturity level
Although soap has evolved from its original intention, it has reached a more mature situation for the distribution and invocation of heterogeneous environmental services, as well as vendor support. Different platforms, Web service that interacts through soap between development languages can be better exchanged.


Because there is no authoritative protocol similar to SOAP as a specification, the various protocols for rest implementation can only be private, and of course need to follow rest, but there are too many areas of detail where there is no constraint. Rest of the future development of the norm will also directly affect whether this part of the design can have a very good vitality.