Home > Web Services > Web Services Overview – REST, SOAP, OData

Web Services Overview – REST, SOAP, OData

January 23rd, 2013 Leave a comment Go to comments

The bigger picture

Technologies are changing, for good or for bad, and we can’t do anything about it except to embrace them and adapt.

In my experience, I’ve found that the topic of web services is quite obtrusive to many developers, mainly due to the fact there are at least a dozen of technologies (by Microsoft alone), a lot of buzzwords and strange acronyms that seem interchangeable at first glance.  It’s overwhelming.

In this part of the article, I’ll try to touch some basic, but important, pieces of information related to web services, which will give you the basic theoretical knowledge to understand the different between the new Asp.Net Web API, the Asp.Net MVC end points and the different services WCF provides.

The need for standards

One of the most common issues involved in web communications is the mismatch in the format of the data sent. Every proprietary system is free to use whatever rules it wishes when composing a message between its modules. With the advance of the internet, however, it became clear that the cost of the synchronization between the different applications/platforms is too high to afford, and software community began to look for a standardized solutions to address the problem.

One of these solutions is SOAP.


What is SOAP ?

The Simple Object Access Protocol (SOAP) is an attempt to define a standard for creating web service APIs. It is a pattern, a web service architecture, which specifies the basic rules to be considered while designing web service platforms. It typically uses HTTP as a layer 7 protocol, although this is not mandatory. The SOAP message itself consists of an envelope, inside of which are the SOAP headers and body, the actual information we want to send. It is based on the standard XML format, designed especially to transport and store structured data. SOAP may also refer to the format of the XML that the envelope uses.

SOAP is a mature standard and is heavily used in many systems, but it does not use many of the functionality build in HTTP. While some consider it slow, it provides a heavy set of functionality which is a necessity in many cases. It might not be the best solution for browser-based clients, due to its custom format.


What is REST ?

The Representational State Transfer (REST) is another architectural pattern (resource-oriented), an alternative to SOAP. Unlike SOAP, RESTful applications use the HTTP build-in headers (with a variety of media-types) to carry meta information and use the GET, POST, PUT and DELETE verbs to perform CRUD operations. REST is resource-oriented and uses clean URLs (or RESTful URLs).

For example :




Note: Having query parameters doesn’t exclude REST, the query parameters can actually complement the restful URL by making it more versatile (thanks Ugarit Ebla for pointing that in the comments ;] )

This kind of URLs syntax greatly improves both visibility and usability. It doesn’t use any query strings, and it also provides certain SEO benefits (the crawlers just love plain text). The body of the REST message can be XML, JSON or any other format, although JSON is usually the preferred choice. On the other hand, you can’t use JSON with SOAP. Or at least not entirely, because SOAP uses XML by definition for it’s envelope. It should also mentioned that REST is, by design, protocol-agnostic, although it is usually used with HTTP. 

Read more: What’s the difference between JSON and XML ?

Atom and AtomPub

The name Atom relates to two similar terms : Atom Syndication Format and Atom Publishing Format
The Atom Syndication Format is a XML-based format used for web feeds (or news feeds). It’s basically an alternative to RSS.

The Atom Publishing Protocol (AtomPub) is a simple HTTP-based protocol used for the management (creation, deletion, update) of web resources – the feeds at first exactly.

And what is OData ?

Remember that part about the need for standardization ?

The Open Data Protocol (or simply OData) is a protocol based on AtomPub and REST. It has most of the REST specifics and more than AtomPub’s specification have defined. It’s designed to define the standard way of communication to a web service. Like SQL for relational data, you don’t care what RDBMS is down there – you simply use SQL to query data. And that’s the idea.

Don’t forget we are talking about specifications here, protocols, not implementations. Whether or not a given framework or library will implement a given functionality is up to the development team. It is also worth mentioning that OData was released by Microsoft, although it is truly open source (just like version 4 of Asp.Net MVC, by the way). It will probably be the protocol of choice for any future service-oriented technologies developed by Microsoft.

What improvements does OData provide over AtomPub ?

AtomPub provides a way of getting, updating and deleting records from a model. It does not provide, however, a data model that defines typed or untyped values on an entity. It also doesn’t provide any kind of a build-in query language to filter the entities we need. More on that later.




– A service architecture
– XML based
– Runs on HTTP but envelopes the message
– Slower than REST
– Very mature, a lot of functionality
– Not suitable for browser-based clients


– A service architecture (resource-oriented)
– Uses the HTTP headers to hold meta information (although it is protocol-agnostic)
– Can be used with XML, JSON or whatever necessary
– Usually used with JSON due to the easily parsable content
– Faster than SOAP
– It uses semantic media types


– A protocol
– Based on HTTP, AtomPub and JSON
– RESTful by design
– Microsoft implementation, yet truly open source
– Used in the latest Microsoft service-oriented technologies (more on that later)


My idea of writing this article was to introduce you to the new Asp.Net Web API, compared to the various services in WCF (SOAP services, WebHttpServices, Data services, etc.) and to the Asp.Net MVC alternative. I decided, however, to first give you this quick introduction so you can know what’s behind the new Microsoft service-oriented technologies (although these terms are platform-agnostic) and why it was used.

In my next article on the subject, I’ll focus on the practical part and the actual technologies/frameworks that use these protocols and patterns.

If you want to read more on the topic, you can check the following document written by Vivin Suresh Paliath, which forms a nice introduction into the differences between SOA, ROA, SOAP and REST in general. 

Like the article ? Share it ! ;)

  1. Navi
    August 22nd, 2013 at 12:28 | #1

    thnx it provide me the correct difference 

  2. Jeff B.
    August 23rd, 2013 at 16:59 | #2

    Hi, just wondering…the last sentence in the SOAP standard definition says "It might now be the best solution for browser-based clients, due to its custom format. " Did you mean "not" instead.  The sentence reads like it should be not.

  3. August 23rd, 2013 at 19:36 | #3

    Hi Jeff, 

    You're right. That was a typo, I just fixed it. 


  4. Jeff B.
    August 23rd, 2013 at 19:47 | #4

    I thought so. :)  One mistyped letter can change the semantics of a statement completely…in writing and in coding. Thanks for the blogging!

  5. August 23rd, 2013 at 19:48 | #5

    Np. Thanks for commenting. ;)

  6. Ugarit Ebla
    November 24th, 2013 at 08:11 | #6

    Your statementt:

    “http://www.developingthefuture.com/index.php?page=foo becomes http://www.developingthefuture.com/foo

    implies that query strings aren’t part of REST, but they could be! IMHO it’s much better to use query strings in a RESTful API than not to, since the order after the resource become less important. Imagine you architect a solution using only /a/b/c/d and realize /a/d/c/d is better! With query strings it wouldn’t matter.

  7. December 5th, 2013 at 19:59 | #7

    Hi Ugarit,

    I agree with you. Having query parameters can actually make the REST URL a little bit more versatile, in my oppinion.

    Thanks for the comment, I added a comment in the text about that. ;]


  8. Mac
    May 14th, 2014 at 14:25 | #8

    This is very, very wrong. Saying REST is for web services is like saying HTML is only for serving up images. The “R” in rest stands for Representational, and that means REST is meant to serve and manipulate data in any format supported by both the client and browser. Furthermore, the HTTP methods are NOT analogous to CRUD operations. These misunderstandings are the reason Microsoft’s various pseudo-REST offerings have been and remain fundamentally broken.

  9. May 19th, 2014 at 16:10 | #9

    Hi Mac,

    Sorry for the delayed approval.

    “Saying REST is for web services is like saying HTML is only for serving up images. ”

    Absolutely. But it’s being associated mainly with web services.

    “Furthermore, the HTTP methods are NOT analogous to CRUD operations.”

    I must agree with this one as well.

    But the problem is that the whole story with REST is quite obscure – we have a set of (not so clear) specifications being interpreted differently by different people. And that’s the reason why the Microsoft’s implementation might be “broken”, in the sense that it’s not strictly adhering the specs.

    However, that’s the practical situation. We have this implementation from Microsoft and other vendors that works and is being actively used. That’s the gap between theory and practice. I understand that what I’ve written might not be 100% true, but I think that the simplification justifies the inaccuracies.

    Thanks for your note, though


  1. January 30th, 2013 at 11:38 | #1

Copyright © Developing the future 2013. Licensed under the CC> BY-NC-ND 3.0 Creative Commons license.       
Audi R8 wallpapers Sony Xperia Z4 Tablet WiFi