Since the introduction of the REST API ins Sage CRM 2019 R2 we can see that there are three types of web service in Sage CRM.
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.
There are differences in design and features between the SOAP and REST APIs. This is partly down to the REST API still being developed and extended. I pointed out in the article "Where next for the REST API?" that this is not a fixed and 'done' API like the existing COM, .NET, SOAP API and even SData API.
The SOAP API
For example when handling users the SOAP API allows for some user data to be queried from the system. The user entity is exposed to webservices and described in the WSDL. This is a very restricted understanding of the entity and not fields are exposed.
<element name="createddate" minOccurs="0" maxOccurs="1" type="xsd:dateTime"/>
<element name="firstname" minOccurs="0" maxOccurs="1" type="xsd:string"/>
<element name="lastname" minOccurs="0" maxOccurs="1" type="xsd:string"/>
<element name="logon" minOccurs="0" maxOccurs="1" type="xsd:string"/>
<element name="updateddate" minOccurs="0" maxOccurs="1" type="xsd:dateTime"/>
<element name="userid" minOccurs="0" maxOccurs="1" type="xsd:int"/>
The SOAP The SOAP webservices are capable of Create, Read, Update, and Delete (CRUD) actions but the user table can only be inserted to using the AddResource action which adds a user that is not enabled for log on. The creation of users as resources prevents the nasty situation of where the web service program could run and create new users which then caused the total users in the system to exceed the number of allowed users in the license. This would then prevent any further logons. To recover from that the users would have to be either deleted, disabled or set as resources.
The REST API
The REST API because of it's roots within the SDATA API uses the same settings within metadata that determines whether a table is exposed to the API. The REST documentation lists those entities that have been tested and are officially supported for CRUD actions. The user table is not one of these.
Unlike the SOAP Web Services which uses the WSDL for schema discovery and that WSDSL is heavily restricted, the REST API uses the concept of a dynamically generated schema that can be interrogated and discovered.
In the REST API we use $prototypes to discover information about the system.
To find out information about an existing table or view exposed to SData we can use
The User table is NOT exposed by default to the REST API. If it was then it would become accessible for CRUD actions using the API and customers would face the same situation of inserting users that would then break the licensing.
In situations where only a listing of user information is required then it is possible to create expose a view to the SDATA and REST APIs.
Database views can be used to derive, calculate, join and transform data from multiple tables into a single source.
The image below shows the creation of a view in the context of the User entity. The view is called vSDataUserList and has been marked as available to SData.
This view then is available as an endpoint within SData.
BUT to enable the view for the REST API the whole User table must be exposed to SDATA.
Using view is available to the REST API but it is not possible to request the prototype and will return an error "Resource kind does not exist".
The view should only be used for reading data.
CostiI think your forum post may have identified an issue. I'll look into it. BUT just doing simple checks my end, I can make requests from clients (on a different domain) to one of our servers without getting any problems..
Is it possible to confire the REST Api to allow requests from different domain? I am developing an application using which in dev mode is served at http://localhost:4200 and calling the REST API results in an error : "Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource."