SOA / Web Services / Java

A Technology Blog

Posts Tagged ‘REST’

JSON vs XML in REST WS

Posted by Vivek on January 8, 2012

One distinctive feature of REST web service is that it supports message formats other than XML or SOAP.  In a REST based web service, resources are identified by a unique URI and can support formats such as XML, JSON, HTML, CSV etc. However, XML and JSON (JavaScript Object Notation) have gained more visibility and are widely used formats. While XML is still the preferred choice, JSON is not far behind than XML.

1. XML is verbose and causes performance bottlenecks. The primary objective behind adoption of REST is to increase the performance of services and XML does not provide good support here.

2. Those using Java can easily parse JSON as it is well supported by javascript clients. Nowadays, all browsers support javascript and browsers like firefox 4 and IE8 also provide special support for parsing JSON. Afterall, JSON is a subset of javascript. Note that not all browsers support encoding and decoding of JSON.

3. There is support in leading XML editors like XML Spy for JSON. Other editors will soon follow the same. However, this will take some time. JSON schema is not widely accepted and is still evolving.

4. Processing JSON requires less effort and is not memory intensive. Fewer lines of code without any dependency on external JARs reduces overhead.

5. JSON can pose several security problems if the processing program contains insecure scripts. There is no standard security mechanism that can be used. JSON is a preferred approach only when the data and parsers are from a trusted source.

6. A variety of XML processors are available in the market. Also, there are techniques to compress XML or accelerate XML processing. JSON has a limted playing field.

 

Advertisements

Posted in Java/J2EE, Miscellaneous, Web Services | Tagged: , , | 1 Comment »

When to use REST based web services?

Posted by Vivek on March 11, 2009

REST expose a much simpler interface than SOAP, with some limitations. Development with REST is easier and quicker and this is the reason why most famous web APIs are REST-based.
 
The limitations are related to the protocol: with REST you are bound to HTTP. So it is difficult to handle different transports like MQ or JMS. So if you are designing an application to be used exclusively on the web, REST could be the option. If you are designing a SOA for an Enterprise, that needs to interconnect to multiple systems using multiple transport/channels and having sophisticated transactions to be modeled with BPMs, then it is better to go with SOAP.
Note than you are going to pay SOAP’s flexibility with development complexity: SOAP interfaces are described by the WSDL standard which looks really complicated and is not supposed to be read by humans.

RESTful applications simply rely on the built-in HTTP security (the HTTPS protocol), with SOAP you can have more sophisticated choices, like WS-Security that lets you encrypt only portions of the messages and moves the security handling from the transport layer to the message layer.

REST is younger than SOAP, so it is not as well supported by commercial products (both BPM and ESB products). However new versions of the major ESBs support REST (ex mule, openesb).

RESTful services do not have a strict describtor, they tried to define something simmilar to WSDL, it’s called WADL (https://wadl.dev.java.net/). The WADL is currently not a common standard the adoption is very low and mostly not wanted for RESTful services.

Even for ESB’s most of the vendors where lacking the support some month ago. But now nearly each big ESB vendor (commercial or open source) supports the RESTful protocol. From the usage of an ESB it is currently not a problem to run RESTful services.

If you plan to run a very big deployment with many data interfaces, you will get great benefits using RESTful Services. REST is based 100% on the HTTP rfc (http://www.w3.org/Protocols/rfc2616/rfc2616.html). Many of the RESTful Interface which you see currently on the internet do not fully support HTTP specification, the result is that they could not benefit from it in terms of performance, caching, content negotiation and security. 
One great reason is to use RESTful interfaces is it can easily support different content-types/mime-types. First you think about, vendor specific XML with a xsd definition, later you would like to support AJAX Mashups and even later you think about to support text formats, reports in PDF, and so on. This is very easy to implement with REST because you query always with the same data query but the requested content type is just different.
Another reason why people are using RESTful interfaces is to be scalable like the web (www) and google. This is possible when you are using plain and simple HTTP protocol. You have support from so many standard product like web proxy caches (like SQUID) or other to scale your application a very low effort. For Social Communities you have have now a new Standard for RESTful Service Security. It is called Oauth (http://oauth.net/) which makes authentication over HTTP very easy.

Some other examples where RESTFul Services are dominant:
Amazon AWS: E.g. they offer Services for Storage (S3) and they have SOAP and REST interfaces but over 90% of the clients are using REST
Google Maps is using RESTful uris to provide cachable map tiles
yahoo API’s are mostly build with RESTful interfaces
RESTful Services are very dominant in lighweight web 2.0 API’s for Mashups like OpenSocial
API.

REST design is good for the database driven applications and when client wants quick integration.

Posted in Web Services | Tagged: | 12 Comments »