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: Develop for Sage CRM | Sage Developer

The API uses standard HTTP status codes - These are the codes that represent the results of operations that you perform against the REST service. They are divided into four major categories:

• 200 - Success
• 300 - Redirection
• 400 - User error
• 500 - Server error

And these are discussed within the documentation and in other blog articles on this community.

It allows the manipulation of resources - The Sage CRM REST service represents the objects exposed in Sage CRM (Company, Case, Quote etc) as resources. This means that a unique URL identifies each resource so that you can manipulate it with standard HTTP methods.

Importantly for this article, it provides a "hypermedia-driven API" - This means that the Sage CRM REST API returns responses that include links to resources available in Sage CRM.

The jargon word for this is "HATEOAS" that stands for "Hypermedia as the Engine of Application State". This is quite a horrible word and could easily confuse anyone.

I think this principle can be explained as the API describes in its responses how it can be used. The results of a request using the Sage CRM REST API will provide URLs to other allowed actions.

The API resources that are officially documented and supported are shown below:

Consider the request to retrieve an opportunity record via the API.

The URL is

http://localhost/sdata/crmj/sagecrm2/-/opportunity('6')

And results in a JSON package that confirms and described the resources that have been retrieved.

And within the overall result set, it describes the relations of this object to other resources.

This can be thought of as a type of dynamic 'schema discovery' allowing a programmer to create a client application that can interactively explore the data available. Please do note that access to data via the REST API is controlled by security profiles and field-level security. That has the effect of limiting access to rows within entities and views. A data source for the API can either be an entity or be a view (READ only) and field-level security will also limit the columns that are returned within the generated JSON.

Another way of finding out more about each of the exposed supported resources is to use $Prototypes.

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

This describes the resources available.

And in turn when the prototype for an individual resource is requested this provides information about the fields and allowed values.