In this article I want to start looking at the SData in action and start to understand what the RESTful API offers. And if we are going to work with SData then we need to have an instance of Sage CRM with which we can play.

Here we need to work with an instance of Sage CRM 2017 onwards.

I want to look at the programmatic way we can interact with Sage CRM. To demonstrate how these calls can be made we don't have to rush to code, instead we can form the necessary requests using a REST client.

There are a number of REST client 'add ons' available for different browsers. REST clients are essential when developing RESTful web services. We can just use any web browser to test simple GETs, but REST clients also provide formatted views of XML and JSON payloads which is helpful. And especially with SData interaction with Sage CRM we can not just use a browser and enter addresses into the browser URL box as this provides us with no way of changing the HTTP headers which are used to pass the authentication credentials.

With a REST client it's also easy to perform all of the HTTP verbs/actions and hit a web service's POST, PUT and DELETE methods.

Within these articles I will assume that you will use the Chrome Advanced REST Client which is available within the web store.

Eventually you will see how you can perform a GET on an SData resource and then see how POSTs can be used to create a new resource or change an existing resource.

In the image below I have used an HTTP 'Get'.

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

as the end point.

But what is the 'stuff' in the Header?

This the encrypted username and password that need to be included in the header to authenticate the request.

You can enter the header either raw that I have used here or using the form. 'Brits' should note that the header has to be 'Authorization' not 'Authorisation'.

The username and password is in the form

• Basic username:password

or

• Basic [email protected]:sm3llys0ck5

The username and password need to be Base64 encoded. You can use the site www.base64decode.org to help you.

When the request is made the instance of Sage CRM 'wakes' and it returns a JSON object in which we can see the resources available to us.

The instance of Sage CRM is now ready for further requests.

If you are not familiar with JSON then I will be discussing JSON a little later in the series as this becomes very important with SData 2.0.

But lets consider the URLs returned.

The important URL for us is the sDataURL.

This will allow us to pull back a SData feed of all the companies in a system but we should realise that this is the same information that is available through the user interface, although from a development point of view it is vital that we should be able to discover this through an authenticated end point. What we can do using the Advanced REST client we could do using a program.

Using the information provided by the getcrmurls endpoint we can make a request for a list of companies. You will note that the authorization information is included in the header,

The request will produce a result.

The result is returned in XML. This is how it is for SData 1.1 in Sage CRM.

I have written before about SData in the article "Understanding SData & how the GCRM Contract is used in Sage Integrations". If you are a member of the Developer Program and want to experiment more with the way in which SData requests are formed then is a set of example URLs that can be downloaded from here.

In the next article we will look at extending query access to custom entities and views in SData.

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