OData
Microsoft has made it obvious that they are taking OData protocol very seriously by integrating it into SharePoint,
Generally speaking, OData extends AtomPub. AtomPub, as specified in [RFC5023] is appropriate for use in Web services which need a uniform, flexible, general purpose interface for exposing create retrieve update delete (CRUD) operations on a data model to clients. It is less suited to Web services that are primarily method-oriented or in which data operations are constrained to certain prescribed patterns.
Let me paraphrase that. If all your service is going to do for your client is “CRUD” on generic data then OData is appropriate. As long as everyone keeps this in mind going forward we should not run into too much trouble. However, there is a problem with this statement. REST is not really appropriate for doing CRUD.
ODBC allows clients to initiate transactions across multiple requests. REST does not allow this as it would violate the stateless constraint. REST does not need this because it is intended to address a completely different layer of the application architecture than ODBC. REST provides a way to deliver Domain services. I.e. If you maintain weather data, REST provides you a easy way to expose “Today’s Weather”, “Last Week’s weather for Detroit”, “Average Rainfall in Orlando for the month of June”. ODBC is aimed at the layer that exposes the data points for a specific place at a specific date and time.
ODBC exposes dumb data, REST exposes intelligently presented information.
In an ODBC application it is the client that does something intelligent with the data before presenting it to the user. In a REST application, usually the client simply makes the “intelligent information” pretty. REST and ODBC are not comparable.
So is OData useful? Absolutely it is useful to people who want to manipulate generic information, like for example SharePoint lists, or data to feed into PowerPivot or Excel. If you have a need to expose a generic data store to a client that will do graphing, statistical analysis, or some kind of visualization like rendering Mars Rover data then it could be very useful.
However, if you want to provide a service that delivers intelligent information that is specific to a particular domain then OData is not appropriate.
Beyond my fear of developers attempting to use OData for unintended purposes there are few other things that I think should be fixed in the OData spec.
The Atom Entry content element should not use application/xml as the media type. The content contains XML that is specifically related to the Entity Data Model and should be identified as such. A media type such as application/EDM-Instance+xml may be sufficient. What would be even better is if that content element contained a link to the CSDL file that defines the EntityType and that is currently accessed by constructing an URI with [Service]/$metadata.
Client side URI construction is really nasty habit to get into. I think for the most part, MS can get away with the construction of query parameters like $skip, $top, and $orderby, but to actually construct the path segments of a URI is just going lead to client-server coupling that will hurt in the future.