Open Data Protocol

The OpenDataProtocol (OData) enables the creation of HTTP-based data services, which allow resources identified using Uniform Resource Identifiers (URIs) and defined in an abstract data model, to be published and edited by Web clients using simple HTTP messages. OData is intended to be used to expose and access information from a variety of sources including, but not limited to, relational databases, file systems, content management systems, and traditional Web sites.

A URI used by an OData service has up to three significant parts: the service root URI, resource path and query string options.

http://services.odata.org/OData/OData.svc/Category(1)/Products?$top=2&$orderby=name \_______________________________________/ \__________________/ \_________________/ | | | service root URI resource path query options

If we look at http://www.odata.org/developers/protocols/uri-conventions and at http://www.odata.org/developers/protocols/operations we can see several examples where OData apparently standardizes the query options by basically defining a query language... essentially reinventing a kind of SQL in the URI. Examples:

The first 5 Product Entries returned in descending order when sorted by the Name property:

 http://services.odata.org/OData/OData.svc/Products?$top=5&$orderby=Name desc

The Description of the first Product in datasource (Somewhat Equivalent to Relational Projection and Quota operations?):

 http://services.odata.org/OData/OData.svc/Products(1)/Description

But note this is not valid (why this does not bring the Descriptions of all the Products?):

http://services.odata.org/OData/OData.svc/Products/Description

This is the right way to do it:

http://services.odata.org/OData/OData.svc/Products?$select=Description

OData has a "network (hierarchical?) operator $expand, that can be used like this:

http://services.odata.org/OData/OData.svc/Categories?$expand=Products

Apparently this fetches the Categories, with its associated Products (since MS implementation of OData uses the EntityFramework? to talk to SQL databases, it can "know" that there is an integrity relationship between Categories and Products (what happens if there are two?). This IMO goes beyond relational (and in to kind of a network/hierarchical model, but it convenience is undeniable, specially since it avoids the redundant data that would result from a traditional join)

Microsoft says that: "The Open Data Protocol (OData) provides a way to unlock your data and free it from silos that exist in applications today, making it easy for data to be shared in a manner that follows the philosophy of Open Data. OData enables a new level of data integration and interoperability across a broad range of clients, servers, services, and tools." And they seem to believe that the way to achieve that is by standardizing the representation of queries in URIs...

I wonder... what is the difference between this and plain passing SQL (or TutorialDee) queries in the URI query string? I also wonder... this new query language... does it have the goal of replacing SQL? What is exactly the advantage of OData over SQL queries? and finally... Is this essentially the creation of NetworkQueryLanguage? on top any datasource? (I see no support for ThetaJoins?... but maybe it is there?) could a RelationalDataProtocol? (possibly based on RelProject or AlphoraDataphor) offer key advtanges that OData does not offer? was relational theory used in the design of OData query language? wouldn't it be nice to have a RelationalDataProtocol? where we could do this:

Select all columns except Description:

http://relationaldata.org/RData/RData.svc/Products?$allbut=Description

Also, rename does not seem to be supported, but wouldn't it be nice to be able to say (to be able to rename a column) :

http://relationaldata.org/RData/RData.svc/Products?$rename(Description,SomethingElse?)

OTOH the case for a $join operation might be hard to sell, something like this:

http://relationaldata.org/RData/RData.svc/Categories?$join(Products,CategoryId?,CategoryId?)

would be nice, but would it return the data using the same hierarchical XML/JSON structure of $expand? or would it return the values from Categories redundantly repeated for each Category tuple?

And finally what is exactly the advantage of the OpenDataProtocol over SQL using HTTP as transport protocol and returning tuples sets represented in JSON or XML? Does this finally proofs that RestIsJustSqlReinvented ?

Seems harmless enough, and perhaps simpler for implementing certain WebServices than SOAP and its related infrastructure. I doubt it will replace SQL or any other database query language, as it appears intended merely to expose data sources over the Web. That seems to wind up being the primary purpose of many WebServices anyway.

...And it's a nice way to turn SqlInjection from a bug into a feature.

OTOH this means that there needs to be a strong security model on the server that determines if the current user has permission to do whatever she is trying to do. It might need to verify it up to the field and operation to field level... IMO some Databases already do that... Maybe OData could be implemented directly on top of a DBMS?