You may have seen the diagram below in other articles and training materials. It is used to explain the hybrid nature of Sage CRM's architecture. It shows both the eWare.dll and the Java-based part which delivers behaviour through the use of Apache Tomcat web apps. This includes the SData RESTful web services.
From when Sage CRM was first developed the product has always been open to integration and extension. There is a range of integration APIs which can be used to address customer-specific integration requirements. And options allow for the extension of the interface rather than integration with 3rd party system.
The diagram below summarises some of the differences between the APIs
The 4 Main toolset options in Sage CRM for the developer are:
- COM API
- .NET API
- SOAP Web Services
- REST Web Services
The Sage CRM provides an open SOAP web services interface, REST interface and application extensions can be created using the COM programming interface and .NET API. There is even a Client-Side scripting interface that can make asynchronous requests within the screen. And the Database is open with a published application data model. But it is the SOAP and REST web services that provide a powerful basis for integration with 3rd party systems. This is especially true when we need to exchange data between systems scattered throughout the web as both these APIs allow a remote system to perform authenticated CRUD (Create, Read, Update & Delete) actions within Sage CRM.
If then we have two main API options that are used for integrations via the web what are the essential differences between the two?
The SOAP Web Services are the classic interfaces that adhere to the SOAP protocol specification. Wikipedia has a good article that explains SOAP. http://en.wikipedia.org/wiki/SOAP
The Sage CRM SOAP web services communicate with the eWare.dll. We can see this in the use of the endpoint that provides the WSDL
or the endpoint to which requests are directed
The presence of two Web Service interfaces in Sage CRM is a product of its design and the fact that Sage CRM is a system in transition from one architecture to another.
The Sage CRM REST API follows the architectural principles inherent within Representational State Transfer (REST).
There are key architectural concepts or constraints that the REST API follows.
- It uses stateless interactions - The Sage CRM REST service doesn’t use login sessions or store other state information on the server. Instead, the client maintains this information about each resource.
- It Communicates over HTTP/HTTPS - The REST service uses common HTTP methods following standard RESTful principles:
- GET - reads data and doesn’t change application state
- POST - creates resources and queries for data using conditions
- PUT - updates resources
- DELETE - removes resources from the database
These are all documented for each resource: http://help.sagecrm.com/2019-r2/RestApiReference/
It is within the REST API that Sage will focus much of its efforts in improving the capabilities for the management of data insert, update and delete in integrations.