SharePoint 2013 has improved OData support. In fact, it offers full-blown OData compliant REST based interface to program against. For those who aren’t familiar with OData, OData is an open standard for querying and updating data that relies on common web standard HTTP. Read this OData primer for more details.
The obvious benefits are:
1. SharePoint data can be made available on non-Microsoft platforms and to mobile devices
2. SharePoint can connect and bring in data from any OData sources
Client Programming Options: In SharePoint 2010, there were primarily three ways to access SharePoint data from the client or external environment.
1. Client side object model(CSOM) – SharePoint offers three different set of APIs, each intended to be used in certain type of client applications.
- Manged client object model – for .Net client applications
- Silverlight client object model – for client applications written in Silverlight
- ECMAScript(JavaScript) object model – for JavaScript client applications
Each object model uses its own proxy to communicate with the SharePoint server object model through WCF service Client.SVC. This service is responsible for all communications between client models and server object model.
2. ListData.SVC – REST based interface to add and update lists.
3. Classic ASMX web services – These services were used when parts of server object model aren’t available through CSOM or ListData service such as profiles, publishing and taxonomy. They also provided backward compatibility to code written for SharePoint 2007.
4. Custom WCF services – When a part of server object model isn’t accessible through all of above three options, custom written WCF services can expose SharePoint functionalities.
Architecture:
In SharePoint 2010, Client.svc wasn’t accessible directly. SharePoint 2013 extends Client.svc with REST capabilities and it can now accepts HTTP GET, POST, PUT, MERGE and DELETE requests. Firewalls usually block HTTP verbs other than GET and POST. Fortunately, OData supports verb tunneling where PUT, MERGE and DELETE are submitted as POST requests and X-HTTPMehod header carries the actual verb. The path /_vti_bin/client.svc is abstracted as _api in SharePoint 2013.
CSOM additions: User profiles, publishing, taxonomy, workflow, analytics, eDiscovery and many other APIs are available in client object model. Earlier these apis are available only in server object model.
ListData.svc is still available mainly for backward compatibility.
Atom or JSON response – Response to OData request could be in Atom XML or JSON format. Atom is usually used with managed clients while JSON is the preferred format for JavaScript client as the response is a complex nested object and hence no extra parsing is required. HTTP header must have specific instructions on desired response type otherwise it would be an Atom response which is the default type.
thanks for posting Parshva, really clear and good references for further reading on Odata and what moved into CSOM.
Thank you Paul.