iDiscussion: REST vs SOAP Web Services

Hi Friends,

download (2) download (1)

I am seeing a lot of new web services are implemented using a REST style architecture these days rather than a SOAP one. Lets step back a second and explain what REST is.

What is a REST Web Service


The acronym REST stands for Representational State Transfer, this basically means that each unique URL is a representation of some object. You can get the contents of that object using an HTTP GET, to delete it, you then might use a POST, PUT, or DELETE to modify the object (in practice most of the services use a POST for this).

Who’s using REST?

All of Yahoo’s web services use REST, including Flickr, API uses it, pubsub, bloglines, technorati, and both eBay, and Amazon have web services for both REST and SOAP.

Who’s using SOAP?

Google seams to be consistent in implementing their web services to use SOAP, with the exception of Blogger, which uses XML-RPC. You will find SOAP web services in lots of enterprise software as well.


images (1)

As you may have noticed the companies I mentioned that are using REST api’s haven’t been around for very long, and their apis came out this year mostly. So REST is definitely the trendy way to create a web service, if creating web services could ever be trendy (lets face it you use soap to wash, and you rest when your tired). The main advantages of REST web services are:

  • Lightweight – not a lot of extra xml markup
  • Human Readable Results
  • Easy to build – no toolkits required

SOAP also has some advantages:

  • Easy to consume – sometimes
  • Rigid – type checking, adheres to a contract
  • Development tools

REST and SOAP are not equivalent concepts and Point are :


  • Depends on one transport protocol (HTTP).
  • Makes full use of the specific features of that protocol (verbs GET, POST, PUT, DELETE, caching, headers, and predefined error codes).
  • Says nothing about the format of the messages passed back and forth. However, since the HTTP verb and URL already define the action to take, the message body must therefore contain only the data.
  • Message security is provided by the transport protocol (HTTPS), and is point-to-point only. If you want to secure the message end-to-end, you have to do it yourself.
  • Originally intended for simple CRUD operations on objects.


  • Independent of the transport protocol (could be HTTP, FTP, TCP, UDP, named pipes, shared memory or even email).
  • Requires only that the transport protocol be able to send and receive text (e.g. on HTTP, only the POST verb is used).
  • Strictly defines the format of the messages passed back and forth. A SOAP message contains the data, the action to perform on it, the headers, and the error details in case of failure.
  • Message security is provided by the WS-* standards, and is end-to-end.
  • Originally intended for arbitrary RPC calls.

Items 2 and 3 in the above lists are the main points of incompatibility.

For consuming web services, its sometimes a toss up between which is easier. For instance Google’s AdWords web service is really hard to consume (in CF anyways), it uses SOAP headers, and a number of other things that make it kind of difficult. On the converse, Amazon’s REST web service can sometimes be tricky to parse because it can be highly nested, and the result schema can vary quite a bit based on what you search for.

Which ever architecture you choose make sure its easy for developers to access it, and well documented.


Reference : Click Here

Thanks, Keep Coding 🙂


iConcept: GET vs POST

 GET vs POST: Which one is better? A 10 point comparison
1. Data Size Restriction in GET: There is a character restriction of 255 in the URL. This is mostly the old browsers restriction and new ones can handle more than that. But we can’t be sure that all our visitors are using new browsers. So when we show a text area or a text box asking users to enter some data, then there will be a problem if more data is entered. This restriction is not there in POST method. We can transfer unlimited data using POST. In PHP by default 8MB of data can be transferred. (can be changed by setting the post_max_size in the php.ini file)
2. Data Type Restriction in GET: As the data transfers through address bar ( URL ) there are some restrictions in using space, some characters like ampersand ( & ) etc in the GET method of posting data. We have to take special care for encoding (while sending) and decoding (while receiving) data if such special characters are present.
3. Security: In GET method data gets transferred to the processing page in name value pairs as a query string in URL, so it is exposed and can be easily traced by visiting history pages of the browser. Data is always submitted in the form of text. So any login details with password should never be posted by using GET method. On the other hand, POST is much more secure. In case of POST, all the name value pairs are submitted in the Message Body of the request.
4. Speed: GET is faster than POST.
5. Bookmarking: There are some special cases where advantage of using GET method is, one can store the name value pairs as bookmark and directly use them by bypassing the form. But you cannot bookmark using POST method.
6. If POST method is used and if the page is refreshed it would prompt before the request is resubmitted but it would not prompt if GET method is used.
7. Uploading files through input type file is possible in POST but not with GET method.
8. There are chances for data lost after server encoding in GET method but no data loss occurs in case of POST method.
9. GET uses STACK method for passing form variables while POST method uses HEAP method for passing form variables.
10. GET can store up to 18 form variables but there is no limit in case of POST method.
Reference : Click Here
Thanks :), Keep Coding:)