Worried about future rest monsters being formed

The greatest value of rest lies in its simplicity. As long as you follow the basic principles mentioned in the previous post, you can directly take full advantage of the inherent architecture advantages of HTTP and web servers, requests including GET requests will be effectively cached by the Web server, and achieve high scalability because they do not need to maintain the various session states. The Web services provided by Google and Amazon are the best evidence. This is a repeat of rest advocates.

However, if we continue to develop in the current atmosphere, over-hyping "rest is a more appropriate technical implementation means for SOA than soap", the dangerous idea of "Future Hope For SOA in rest" (the theme discussed above), and the final result of it, it may be a two-win situation that hurts both rest and does not benefit SOA.

What should I do?

Currently, the (enterprise-level) SOA service must be able to automatically discover the exact service endpoint, interface, and XML schema structure for consumers who are interested in calling the service. Discoverability is often included in the eight SOA principles listed by Thomas ERL. What's infoq's top 10 SOA principles? The third and seventh principles are also related to this (with a note, I think the more I think this "Top Ten Principles" will become, the more I feel like it will become, especially the last three ).

Unlike soap, restful web services have no envelope mechanism and only bare payload. The content of payload is usually Pox (plain-old XML ), of course, some people use JavaScript objects to express JSON. For XML alone, if only one instance is used, the exact schema structure cannot be determined. Restful Web Services lacks an envelope header mechanism like soap, which can be used to indicate related metadata, such as XML Schema. Unlike soap, there is also a WSDL partner, to describe various service-related metadata, so the above discoverability principle cannot be satisfied (some hard-spoken rest advocates say that service metadata can be expressed through MIME type, but this is too far-fetched ). Of course, as long as the service provider publishes a clear description of the Service API through the website and sets it in advance, restful web services can also reach a successful task. Such examples are too many in the world of Web 2.0, simply put, such a service lacks a mechanism for consumers to automatically explore and utilize automated tools to facilitate service assembly and development.

With the rest fever, more and more people are discussing whether the rest is similar to soap and the problem of descriptive language (for example, here and here ). Wadl is a product designed to meet discoverability requirements. Sun has incorporated it into the new JAX-RS (here is a good introduction to wadl ). Someone criticized the JAX-RS and pointed out that it was like the JAX-WS to soap, rooted in the framework of the object-oriented programming mechanisms and architecture of corba idl and Java interface, hard to rest. However, as mentioned in the previous post, the rest application design concept and such practices will be incompatible. In other words, it will not encourage developers to treat rest as "just another soap", and completely ignore the rest design concept. The original spirit and value of rest will be lost.

In addition to wadl, if restful services need to specify various mandatory service policies, such as service level, security (identity authentication, encryption, signature ...), in addition, do attributes such as reliability and transactions also need a header to put these attributes? According to this trend, what can we do to block the rest support manufacturers and turn it into another soap?

I still remember the birth of soap, which can be traced back to the history of Dave winer, Don box and other earliest development XML-RPC (can refer to Wikipedia's records )? Since the development of soap has changed from RPC-oriented to file-oriented, and the complexity has increased, Dave winer, the founder of XML-RPC, has switched to RSS due to various factors. I still remember that, about nine years ago, When RSS was still in Version 1.0, it was generally assumed that the full name of RSS was "rich site summary" or "RDF Site Summary ". However, since winer's active participation in the formulation of RSS 2.0, "RSS" began to represent "Really Simple Syndication ". His meaning on the Meaning represented by the "RSS" letter clearly shows his emphasis on "Simplicity.

With the use of rest for enterprise-level SOA applications, rest seems to be under increasing burdens. The launch of wadl specifications is just the tip of the iceberg. We have to ask, let rest repeat the original from XML-RPC all the way to soap 1.2 of the complex history, is it fully positive significance?