what is SOAP, REST, JSON, XML? Difference between POST and GET and when to use?

Actually, SOAP and REST are used for the API integrations in webservices. API’s are used to connect the two different platforms.

Where as JSON and XML is the schemas which is used to return the output from the REST and SOAP.

So SOAP & REST are webservices.

Okay, what’s a webservice?
In a nutshell, Webservice is a software that’s platform independent means If you create a webservice in Java Language and host it on a server, an application written in PHP/.NET/C# /iOS etc.. can use that application. As simple as that.

ex: Imagine those websites that integrate facebook API to use the same technology as that of facebook. It’s just not possible. So facebook creates a webservice and exposes it to all these websites, which uses it for authentication.

Now let’s move on to REST & SOAP -> They are simply two different flavours of webservices.

                             Webservices that use REST framework are called RESTFUL webservices.

REST (Representational State Transfer) was introduced and defined in 2000 by Roy Fielding. It has a client/server relationship.

                                              REST is a design pattern for HTTP applications that the web is based on. It’s a way for web clients such as browsers to identify documents on a web server that the client wants to access in some way. Typically the browser just wants to view a copy of the document or “GET” the document. Although it also has other methods that can allow the client to update “PUT”, delete “DELETE”, or even create new documents “POST”.

SOAP((Simple Object Access Protocol)) is encoding scheme that tries to encode not only the message but the entire web service using a document shared between the client and the server known as a WSDL file (A language that describes the provider service.).

              WSDL (Web Service Description Language) : when you use web service and add a web service to your project, your client application doesn’t know about web service Functions. the WSDL file has some descriptions about web service functions and etc. and the type of this file is XML.

One of the most important characteristics of SOAP is that it uses XML rather than HTTP to define the content of the message.

  • SOAP is good for applications that require formal contracts between the API and consumer since it can enforce the use of formal contracts by using WSDL (Web Services Description Language).
  • Additionally, SOAP has built in WS-Reliable messaging to increase security in asynchronous execution and processing. (WS-Reliable messaging describes a protocol that allows messages to be delivered reliably between distributed applications in the presence of software component, system, or network failures.)
  • Finally, SOAP has built-in stateful operations (Stores the data for further use). REST is naturally stateless.

Stateless means there is no memory of the past. Every transaction is performed as if it were being done for the very first time.

statefull means that there is memory of the past. Previous transactions are remembered and may affect the current transaction.

Some would argue that because of these features, as well as support for WS_AtomicTransaction and WS_Security, SOAP can benefit developers when there is a high need for transactional reliability.

Why we use REST + JSON?

First, REST is easy to understand: it uses HTTP and basic CRUD operations (Create, read, update and delete), so it is simple to write and document. This ease of use also makes it easy for other developers to understand and write services against.

REST also makes efficient use of bandwidth.REST is designed to be stateless, and SOAP reads can be cached for better performance and scalability.

But what makes JSON better? To understand that one only needs only to look at the differences in code.

Take a situation in which we need to retrieve user information from a database. A SOAP call over POST HTTP to process this request is relatively long– over 10 lines. The return is similarly just as dense, including superfluous data clouding the requested information in the middle of the response.

Taking the same scenario, JSON, using a RESTful orientation over HTTP could call and retrieve the same information all in about 4 lines. It’s quickly apparent that SOAP, in comparison to JSON, is bulky and hard on the eyes.

What JSON lacks is it’s limited utility. No security is required in individual responses & returns, and it can’t work without an HTTP transport, whereas SOAP can.

SOAP is designed to support expansion, so it has all sorts of other acronyms and abbreviations associated with it, such as WS-Addressing, WS-Policy, WS-Security, WS-Federation, WS-ReliableMessaging, WS-Coordination, WS-AtomicTransaction, and WS-RemotePortlets.

The point is that SOAP is highly extensible, but you only use the pieces you need for a particular task. For example, when using a public Web service that’s freely available to everyone, you really don’t have much need for WS-Security.

Part of the magic is the Web Services Description Language (WSDL). This is another file that’s associated with SOAP. It provides a definition of how the Web service works, so that when you create a reference to it, the IDE can completely automate the process. So, the difficulty of using SOAP depends to a large degree on the language you use.

One of the most important SOAP features is built-in error handling. If there’s a problem with your request, the response contains error information that you can use to fix the problem. Given that you might not own the Web service, this particular feature is extremely important; otherwise you would be left guessing as to why things didn’t work. The error reporting even provides standardized codes so that it’s possible to automate some error handling tasks in your code.

An interesting SOAP feature is that you don’t necessarily have to use it with the HyperText Transfer Protocol (HTTP) transport.(You can use SOAP with HTTP/HTTPS/SMTP etc)

Principles of REST

  • Resources -> expose easily, understood directory structure.
  • Representations -> transfer JSON or XML to represent data objects and attributes.
  • Messages-> use HTTP methods explicitly (for example, GET, POST, PUT, and DELETE).
  • Stateless-> interactions store no client context on the server between requests. State dependencies limit and restrict scalability. The client holds session state.

    HTTP methods

    Use HTTP methods to map CRUD (create, retrieve, update, delete) operations to HTTP requests.

What is HTTP ?

The Hypertext Transfer Protocol (HTTP) is designed to enable communications between clients and servers. HTTP works as a request-response protocol between a client and server.

There are two commonly used methods for a request-response between a client and server are: GET and POST.

  • GETRequests data from a specified resource (Retrieve only information)
  • Regardless of how many times it repeats with the same parameters, the results are the same.
  • GET requests can be cached.
  • GET requests remain in the browser history
  • GET requests can be bookmarked
  • GET requests should never be used when dealing with sensitive data
  • GET requests have length restrictions. When sending data, the GET method adds the data to the URL, and the length of a URL is limited. Maximum URL length is 2048 characters.
  • GET requests should be used only to retrieve data
    • POSTSubmits data to be processed to a specified resource
Request that the resource at the URI(Uniform Resource Identifier) do something with the provided entity. Often POST is used to create a new entity, but it can also be used to update an entity.
    • POST requests are never cached. POST method used when sending passwords or other sensitive information.
    • POST requests do not remain in the browser history So POST is a little safer than GET because the parameters are not stored in browser history or in web  server history.
    • POST requests cannot be bookmarked
    • POST requests have no restrictions on data length


      Store an entity at a URI.

    • PUT can also create a new entity or update an existing one like POST.
    • But they both serve a different purpose. It’s quite possible, valid and even preferred in some occasions, to use PUT to create resources, or use POST to update resources.So use PUT when you can update a resource completely through a specific resource URI. For instance, if you know that an article resides at http://example.org/article/1234, you can PUT a new resource representation of this article directly through a PUT on this URL.But if you do not know the actual resource location, for instance, when you add a new article, but do not have any idea where to store it, you can POST it to an URL, and let the server decide the actual URL.
    • PUT replaces an existing entity. If only a subset of data elements are provided, the rest will be replaced with empty or null.


      Update only the specified fields of an entity at a URI.


      Request that a resource be removed; however, the resource does not have to be removed immediately. It could be an asynchronous or long-running request.

      HTTP status codes

      Status codes indicate the result of the HTTP request.

      • 1XX – informational
      • 2XX – success
      • 3XX – redirection
      • 4XX – client error
      • 5XX – server error

        Media types

        The Accept and Content-Type HTTP headers can be used to describe the content being sent or requested within an HTTP request. The client may set Accept to application/jsonif it is requesting a response in JSON. Conversely, when sending data, setting the Content-Type to application/xml tells the client that the data being sent in the request is XML.


JSON & XML are basically two different formats to exchange data. I’ll give an example here. Say a website has to send credentials(username & password) to facebook for authentication.

In Advance way -> JSON and XML are both encoding schemes. An encoding scheme is a way of representing or “packaging” information for transmission.So basically they provide a standard way for the transmitter of a message to be understood by any receiver of the message anywhere in the world.

This is how it looks.




    {“username”:”yeswanthdevisetty“, “password”:”12345“}

The data that’s transfered is same in both the cases. It’s just that the formats are different. So, JSON & XML are nothing but, different formats used for data exchange between webservices.

Advantage of JSON over XML

  1. JSON does the same thing as XML but using less bandwidth.
  2. JSON is much simpler than XML. JSON has a much smaller grammar and maps more directly onto the data structures whereas  XML contains start tag and end tags. Moreover it takes more number of characters to show data as compared to JSON.
  3. JSON is light weighted. Hence it is faster than XML whereas Due to tags and additional data, XML becomes heavy. Hence it is not as fast as JSON.

Comparison JSON vs XML







JSON is much simpler than XML. JSON has a much smaller grammar and maps more directly onto the data structures.


XML is extensible because it is a mark-up language

JSON is not extensible and a document markup language. So it is not necessary to define new tags or attributes to represent data in it.

Interoperability (the ability of computer systems or software to exchange and make use of information.)

JSON has the same interoperability potential as XML.

Human Readable

JSON is much easier for human to read and write than XML. It is also easier for machines to read and write.

Exchange Formats

XML can be used as an exchange format to enable users to move their data between similar applications

The same is true for JSON

However XML also has security and other capabilities that are absent from JSON.


XML provides a structure to data so that it is richer in information

The same is true for JSON.

However XML can provide deeper structuring than JSON supports. It can also handle more extended content types.


XML is easily processed because the structure of the data is simple and standard.

JSON is processed more easily because its structure is simpler.

Again this is entirely subjective. See the link provided in the links section on machine timings testing.

Code Re-invention

There is a wide range of reusable software available to programmers to handle XML so they don’t have to re-invent code

JSON, being a simpler notation, needs much less specialized software

JSON is mainly available in JavaScript and not in a wide range of programming environments. Further it is not the simplicity of the syntax, it is the drastically reduced capabilities. Hence JSON only provides very limited functionality.

XML separates the presentation of data from the structure of that data.

XML requires translating the structure of the data into a document structure.

JSON structures are based on arrays and records.

This is only in the context of the data within a web browser memory. Whereas XML is the native format that underpins the spreadsheets, databases and array stores that JSON content must ultimately be persisted to and from!

A common exchange format

XML is a better document exchange format. Use the right tool for the right job.

JSON is a better data exchange format.

Again this is entirely subjective and no metrics are being given here. What defines “better”? Clearly JSON is significantly less capable and restricted in it use cases. Therefore “your mileage may vary in actual use” would be an appropriate caution here when trying to measure what is “better” where and how.

Data Views

XML displays many views of one data

JSON does not provide any display capabilities because it is not a document markup language.

XML has broader applicability. Therefore you can write once, use everywhere. While JSON can expect to be changed into XML for such extended uses.

Self-Describing Data

This is a key XML design objective.

XML and JSON have this in common.

However XML has richer semantics available than JSON.

Complete integration of all traditional databases and formats

(Statements about XML are sometimes given to a bit of hyperbole.) XML documents can contain any imaginable data type – from classical data like text and numbers, or multimedia objects such as sounds, to active formats like Java applets or ActiveX components.

JSON does not have a <[CDATA[]]> feature, so it is not well suited to act as a carrier of sounds or images or other large binary payloads. JSON is optimized for data.

Visual content is data! Ask the FBI analyzing the recent Boston attacks. One could also say that JSON is limited to only simple basic data content and lacks extended validation such as code values, date and number formatting.


XML and JSON both use Unicode.

XML and JSON both use Unicode.

However JSON has limitations in its use of encoding and exchanges.

Open and extensible

XML’s one-of-a-kind open structure allows you to add other state-of-the-art elements when needed. They can always adapt your system to embrace industry-specific vocabulary.

Those vocabularies can be automatically converted to JSON, making migration from XML to JSON very straightforward.

Exactly, if you have XML it is trivial to generate JSON. The reverse is not the case however.


XML is easily readable by both humans and machines

JSON is easier to read for both humans and machines

This is an entirely subjective statement. The better answer is that well written XML and JSON are equivalent for human and machine handling.


XML is document-oriented.

JSON is data-oriented. JSON can be mapped more easily to object-oriented systems.

The reverse is an issue however, objects do not necessarily map easily to documents. Plus not all content is objects; it actually constrains the use model. XML on the other hand is well equipped for use as object-oriented content as well as documents.


XML is being widely adopted by the computer industry

JSON is just beginning to become known. Its simplicity and the ease of converting XML to JSON make JSON ultimately more adoptable.

The use of JSON is limited to web client-server scenarios. Within that domain it is popular. Outside of that domain XML completely dominates.

REST-JSON has several advantages over SOAP-XML


REST-JSON is a lot smaller and less bloated than SOAP-XML therefore you will be passing much less data over the network, which is particularly important for mobile devices.


REST-JSON is also easier to parse the data so therefore easier to extract and convert the data, so therefore requires much less from the CPU from the client.


REST-JSON provides improved response times and server loading due to support from caching


REST-JSON interfaces are much easier to design and implement.


For these reasons REST-JSON is generally preferred to SOAP-XML for mobile application which require a web service to retrieve data from a web service, where there is no need to the heavy-weight XML structure.

SOAP-XML is generally preferred when:

  • passing around a lot of text since XML excels and wrapping and marking up text.
  • you require secure, transactional services such as banking services.

Due to the strict nature of SOAP-XML any changes in the server code needs to be implemented on any and all clients.

Soap Vs Rest

SOAP is definitely the heavyweight choice for Web service access. It provides the following advantages when compared to REST:

  • Language, platform, and transport independent (REST requires use of HTTP)
  • Works well in distributed enterprise environments (REST assumes direct point-to-point communication)
  • Standardized
  • Provides significant pre-build extensibility in the form of the WS* standards
  • Built-in error handling
  • Automation when used with certain language products

REST is easier to use for the most part and is more flexible. It has the following advantages when compared to SOAP:

  • No expensive tools require to interact with the Web service
  • Smaller learning curve
  • Efficient (SOAP uses XML for all messages, REST can use smaller message formats)
  • Fast (no extensive processing required)
  • Closer to other Web technologies in design philosophy
There are some important differences between SOAP and JSON:

  • The content of a SOAP message is XML data, whereas a JSON message contains JSON data. JSON and XML are different encoding mechanisms for describing structured data. JSON tends to be a more efficient encoding mechanism, so a typical JSON message will be smaller than the equivalent XML message.
  • JSON is easy to integrate in JavaScript applications, but XML isn’t. This makes JSON a preferred data format with many mobile application developers.
  • SOAP provides a mechanism to add Headers to a message, and a family of specifications for qualities of service (such as security configuration, and distributed transactions). JSON does not provide this mechanism, it instead relies on the services of the underlying HTTP network protocol. This results in fewer options for securing and configuring a workload.
  • SOAP web services are described using WSDL documents. JSON web services are structured less formally; they tend to be loosely coupled and prefer documentation by example.
  • SOAP web services have an explicit error format involving SOAP Fault messages. There’s no equivalent for JSON.
There are also many similarities between JSON and SOAP:

  • The CICS implementation of JSON is derived from the SOAP architecture, and shares many of the concepts and artifacts.
  • Both involve offline utility programs that assist with mapping application data to and from the external data representation. For SOAP there is DFHLS2WS and DFHWS2LS, for JSON there is DFHLS2JS and DFHJS2LS.
  • The deployment mechanism for both technologies involve a PIPELINE resource, a WEBSERVICE resource, and a URIMAP resource.

Let us understand the difference between JSON and XML in detail.

 JSON stands for “Java Script and Object Notation”.  XML stands for “Extensible Markup Language”.
Syntax and Verbosity JSON is much simpler than XML. JSON has a much smaller grammar and maps more directly onto the data structures.  XML contains start tag and end tags. Moreover it takes more number of characters to show data as compared to JSON.
Speed  JSON is light weighted. Hence it is faster than XML.  Due to tags and additional data, XML becomes heavy. Hence it is not as fast as JSON.
Document Sharing  Json typically is used to exchange traditional data formats like string, array and integers.  XML allows you to include data types like images, charts, and graphs which makes it more rich if you have to share and exchange such data.
Orientation  Json is data oriented, hence it can be easily mapped.  XML is document oriented, hence it requires more effort to map.
Usage  Used where speed is concern. For example: Mobile Application.  Used with SOAP web services to exchange data, used for configuration data.

The selection of JSON or XML soley depends upon above parameters as well as design of application.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s