Geeks With Blogs
Jeff Krebsbach

Before we can build these types of applications, we must answer two questions:

What is REST?

Rest is an “Architectural Style” developed to help provide a standard strategy for data interactions over the internet (Port 80 – HTTP) using entirely existing web based technologies using the HTTP verbs we all know and love(GET, POST, PUT, DELETE).  How is it different than Web Services? 

Web Services are designed to abstractly decouple systems.  A call over port 80 can initiate an invoicing process, update warehouse inventory, or initiate a long running transaction.  Every time we have a different need for a web service, we start anew.  Each method is implemented separately, a wsdl is defined describing the specific method, a contract is written describing what data must be provided and what data will be returned.

REST is a protocol designed to expose data.  Web Services have contracts on methods.  Every Web Service interaction must be a method call, and every method call has a data contract.  In contrast, REST works on a structured query language intended to expose data for reading and writing.  Let’s take an example site example.com that wants to expose their Users table.

http://example.com/users/

This will be our fundamental REST example.  What this means is from the address “example.com”, we want to see all users.  An XML result will be returned in a standard format that will enumerate the objects and their properties to then be used.

http://example.com/users/{user}

Taken one step further, if we provide a user ID in the request string, we will instead receive only one user instead of the whole list in the response.

http://example.com/locations/

Now we will see all locations instead of all users

Along with this and a few other ways of querying the data, REST also exposes standard methods of exposing relationships, inserting, updating, and deleting data.  Because we have one way to interact with the data, we do not need to defined WSDL files or need to concern ourselves with how to interact with a specific version of a given web service.  The implementation of those commands is left as an exercise to the reader.

What is OData?

OData is a framework built in WCF to fully automate the REST protocol.  Any REST enabled data sources can therefore be leveraged using an OData connection over the web.  A data provider does not need to use OData, they simply need to use REST.  Likewise, a consumer could choose not to use OData, they digest the REST however they see fit.  OData allows us to not have to worry about the specifics of implementing REST, and instead use OData to leverage the heavy lifting and can treat REST as an open standard for exposing tables.  And for our security aficionados, OData allows us to restrict data selects, updates, and inserts in the most granular levels (ie:  This user group may select the data but not update, this group may not interact with the data in any way)

Most importantly to me:  Because of the decoupled, uniquely addressable, and standardize approach to OData, I don’t have to worry about the five different GetUsers web service method that invariably arises as each department has their own specific needs for what a “User” object must look like.  The users table is simply available for all OData consumers to digest as they see fit.

Likewise, OData makes no presuppositions on what the data source truly is.  Using WCF, with a few clicks I can publish an OData data source pointing directly at my SQL Server database, or I can create custom CLR entities that are based on CSLA objects, or the data is being pulled from an Access database on a Win NT Server – the only thing important to the OData consumers is that the REST endpoint is available.  Everything else is seamless to the consumer.

Posted on Thursday, July 15, 2010 8:02 PM | Back to top


Comments on this post: RESTful Applications and the Open Data Protocol

No comments posted yet.
Your comment:
 (will show your gravatar)


Copyright © jkrebsbach | Powered by: GeeksWithBlogs.net