JAX-RS. Is SOAP going to lose its market?

Hi Guys,

Its been quite long since done something different to post about. Today am going to talk about RESTFul web-services.

Before moving to JAX-RS it is very important to know about RESTFul, what does this actually mean. On hitting just the first link on Google I came across the wikipedia page for this, must say a very well-written page and got lots of my understanding clarified from this.
http://en.wikipedia.org/wiki/Representational_State_Transfer

And then I understood that its nothing for me to bang my head on but a software architecture, now the first aim is study this architecture :)

REST style is a client-server interaction, client request and server responds. The best thing I liked about this page is this line: RESTful applications maximize the use of the pre-existing, well-defined interface and other built-in capabilities provided by the chosen network protocol, and minimize the addition of new application-specific features on top of it.

This means no need to set up lot of configurations, just write the business and move on.

Now the next question which hit me, do we actually need it, we have the famous SOAP protocol. Then why do we require Rest now. Check this out:

SOAP RPC contrast

SOAP RPC over HTTP, on the other hand, encourages each application designer to define a new and arbitrary vocabulary of nouns and verbs (for example getUsers(), savePurchaseOrder(...)), usually overlaid onto the HTTP POST verb. This disregards many of HTTP's existing capabilities such as authentication, caching and content type negotiation, and may leave the application designer re-inventing many of these features within the new vocabulary.^[8] Examples of doing so may include the addition of methods such as getNewUsersSince(Date date), savePurchaseOrder(string customerLogon, string password, ...).

This is something more I found and found very useful:

Areas REST works really well for are:

• Limited bandwidth and resources; remember the return structure is really in any format (developer defined). Plus, any browser can be used because the REST approach uses the standard GET, PUT, POST, and DELETE verbs. Again, remember that REST can also use the XMLHttpRequest object that most modern browsers support today, which adds an extra bonus of AJAX.
• Totally stateless operations; if an operation needs to be continued, then REST is not the best approach and SOAP may fit it better. However, if you need stateless CRUD (Create, Read, Update, and Delete) operations, then REST is it.
• Caching situations; if the information can be cached because of the totally stateless operation of the REST approach, this is perfect.

That covers a lot of solutions in the above three. So why would I even consider SOAP? Again, SOAP is fairly mature and well-defined and does come with a complete specification. The REST approach is just that, an approach and is wide open for development, so if you have the following then SOAP is a great solution:

• Asynchronous processing and invocation; if your application needs a guaranteed level of reliability and security then SOAP 1.2 offers additional standards to ensure this type of operation. Things like WSRM – WS-Reliable Messaging.
• Formal contracts; if both sides (provider and consumer) have to agree on the exchange format then SOAP 1.2 gives the rigid specifications for this type of interaction.
• Stateful operations; if the application needs contextual information and conversational state management then SOAP 1.2 has the additional specification in the WS* structure to support those things (Security, Transactions, Coordination, etc). Comparatively, the REST approach would make the developers build this custom plumbing.

So after reading about this I can say that SOAP is not going anywhere and still has a long time to go but RESTFul services will definitely be the next biggie in town.