• Tweet

• Tweet

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 :

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

becomes

http://www.developingthefuture.com/foo

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.

Summary

SOAP

– 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

REST

– 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

OData

– 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.