I said in my last article that SData 2.0 can not be considered a 'green field' solution because SData has been already used through out Sage CRM right from the start of the move to the new Java based architecture.

The desire for compatibility between SData 1.1 and SData 2.0 and what it may mean for the RESTful API that we will use in Sage CRM is the focus for this article.

Just consider the existing SData based integrations

Things like the Sage CRM mobile apps for iPhone and Android also use SData and one of the priorities of my Sage colleagues working on the new SData 2.0 standard was that "Your SData 1.x compliant implementation is automatically compliant to SData 2.0".

Although the new SData 2.0 standard is primarily forward looking, my colleagues tried to avoid forcing existing products to embark on a forced-change route without a well-founded reason. And because Sage CRM's implementation of the RESTful API was originally ReadOnly there is only a minor impact on those of us working with Sage CRM's SData.

The key points my colleagues the Sage CRM developers noticed when they starting working with SData 2.0 was that

• There was now a smaller set of "REQUIRED" or "MUST" compliance rules.
• Things that were originally mandatory had become "guidelines"
• And the standard supports both Atom/XML and JSON formats.

The key aspects that I certainly noticed when I started using the RESTful API based on the SData 2.0 standard was that:

• The standard builds on SDATA 1.x, but does not replace it
• It is easier to implement and easier to use
• It seems a much more RESTful API
• Authentication has not changed (Basic and Digest)

And SData 2.0 is about choice. The most visible choice that our Developer took was the one between returning results in XML-based ATOM format or in JSON format.

• JSON is returned in the new RESTful API version.

This is a fundamental change to SData and an opportunity to confidently enter the arena of modern, web-based applications.

In SData 1.1 we can use $schema to discover information about the system.

e.g.

• http://localhost/sdata/crmj/sagecrm/-/$schema

or to find out information about an existing table or view exposed to SData.

• http://localhost/sdata/crmj/sagecrm/-/company/$schema

We can use a REST client like the Chrome Advanced REST client to retrieve these.

Note: We do not have to pass a username and password in the header as authentication is not required to access the schema.

In SData 2.0 we use $prototypes to discover information about the system.

e.g.

• http://localhost/sdata/crmj/sagecrm2/-/$prototypes

Note: The end point for the request is different. We are going to sagecrm2 here NOT sagecrm.

To find out information about an existing table or view exposed to SData we can use

• http://localhost/sdata/crmj/sagecrm2/-/$prototypes/Company

Note: The order of reference to the entity and its prototype is different in SData 2.0 than the order of reference to the schema and the entity in SData 1.1.

The most dramatic change is not in how the request is made but rather the result that is returned as this is not in JSON not XML.

If I use SData 1.1 to retrieve information from an entity (company) I can use the URL

• http://localhost/sdata/crmj/sagecrm/-/company('28')

And this returns the XML

But if I use SData 2.0 to retrieve the same information from the custom entity then the URL would be

• http://localhost/sdata/crmj/sagecrm2/-/company('28')

And the result is in JSON format.

The JSON format allows SData to operate outside the strictures of the ATOM protocol - originally designed for news syndication. SData expands from the tools and formalisms present in the xml world, to the lighter and more dynamic world of JavaScript consumers.

My next article will take a closer look at JSON as not everyone may be familiar with this way of describing data.

The articles in the series are:

1. Sage CRM's RESTful API, An Introduction
2. Architecture and Web Services
3. Working with an instance of Sage CRM
4. Extending query access to custom entities and views in SData
5. Thinking about security
6. SOAP CRUD vs REST CRUD
7. Limitations of SData 1.1
8. Compatibility as a priority
9. What is JSON?
10. SData 2.0 CRUD