The SData standard has always been about enabling all types of Sage applications, whether they are desktop, server, or web-based systems to communicate with each other easily. The standard provides the basis of the RESTful APIs that can be used by our own programs, third-party applications and web sites.

There are limitations with the SData 1.1 standard. Part of these limitations lie behind the reason why the main RESTful API is ReadOnly.

SData was originally developed with a very tightly defined vision. Its purpose was to enable Sage applications to produce reusable solutions. The main goal was provide the structure and rules for application integration and within Sage that meant CRM and accounting and business management system integration.

This lead to a result that was generally appropriate for application integration but too tightly and exactly defined for more general ad hoc development. And the tightness of the standard meant that not all applications within Sage were able of meeting all of those stringent requirements without considerable efforts.

SData 1.1 was designed with the expectation that integration with accounting systems was its primary purpose and this caused challenges in designing more general behaviour. Within a Sage CRM context this meant difficulties in creating a full CRUD API capable of handling a wide variety of custom scenarios that was not well served by SData requirements aimed at solving a totally different use case.

The central standard team recognised this and the working group decided to position SData as a protocol toolkit.

SData 2.0 has changed to focus on mechanisms that are solutions to general, day-to-day problems: e.g. how to do paging, how to invoke operations, etc.

The Sage CRM development team are part of the SData development community. Because most of the existing requirements associated with SData 1.1 were relaxed this allowed the CRM development team more freedom of decision in their creation of the new APIs for Sage CRM.

But SData 2.0 is not a 'green field' solution — it emerges in a setting where a substantial number of solutions are already present.

It is that priority for compatibility between SData 1.1 and SData 2.0 and what it means for our RESTful API that I will cover in the next article.

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