1. The whole idea of Web Service is simplifying data access as much as possible without
compromising security of services. That's where REST outplays SOAP. The system
should be designed as Resources and should be identified by URLs. Then the services
should be accessed by a small set of remote methods describing the actions to be
performed on the resource. This is how REST smoothly fits into such architecture as a
natural choice when services are stateless and interpreted as Resource URL.
For example, the best way make a POST request using REST :
http://127.0.0.1:8080/myrestservices/loanservice/acceptLoan with the JSON / XML as the
body of the request.
RESTful styles perfectly suits for AJAX Tools where multiple web service calls might be
performed very frequently. SOAP suffers from huge overhead of Headers and heavy XML
payloads even for a simple service call.
REST should be the used specially where Bandwidth is limited such as PDA and Mobile
Devices.
Particularly REST can be easily implemented into existing system of URL oriented static
resources without much refactoring or change in existing system architecture.
Since SOAP needs to carry lots of additional information like Quality of
Service, WS Transaction, Security etc. its suitable for integrating complex heterogeneous
systems and specific cases where a service call tends to needs to perform multiple
operations in a blocking mode and needs to communicate signals back and forth between
service provider and consumer before performing a WS-Transaction.
Otherwise, its always better to simple use REST binding for web service and intercept the
service call to ensure security and QOS and then perform the actual transaction without
overloading the headers.
Proxy Servers can be setup to cache stateless services effectively.

2. Accessing REST services normally won't require any specialized webservice clients
because REST relies on HTTP methods so that any Browser can make
the RESTified service calls.
Now why should we use JSON as the defacto standard for data exchange both for making
a REST service call and communicating between services.
JSON seamlessly integrates with JavaScript and Python as a simple Map Data Structure
whereas XML always required an additional syntax to define its grammer and it has a
hierarchical complex data structure.
User does not need to keep on creating new tags or attributes to represent new data
in JSON as user can simply represent them using Key-Value pairs. In JSON, a Value can
be represented as a nested key-value structure recursively.
JSON support arrays {“Orders”:["Order":"[Id:123]...."]} and is more elegant and compact. It
does not suffer from the - 'how to distinguish an attribute from a child element'
problem.
JSON is fully optimized for exchanging lightweight data i.e. its not suitable for exchanging
Sounds / Images / Binary executable .
XML is more suitable for heavy-weight payloads which is not recommended for Web
Service.
But again handling XML requires specialized knowledge whereas JSON code can be
either converted into simple JSONObject beans that can simply be looked up for child
beans.
So JSON is best for exchanging Data, where as XML is suitable for exchanging
Documents.
Any Web Service Provider should adopt REST and JSON for keeping the services highly
scalable and making fast service calls and providing best user experience over web.

3. References :
JSON vs XML code comparison : http://www.25hoursaday.com/weblog/PermaLink.aspx?
guid=39842a17-781a-45c8-ade5-58286909226b
JSON Wrapper : http://www.jspon.org/