Less Is More: Improving by Reducing REST Calls

One of the challenges when building an application that uses the Content and Experience Cloud Delivery API is improving the performance by reducing the number of API calls that the client application has to make.

The normal flow is to search for items, and then iterate over the number of items to get to the content. This can lead to a large number of REST calls being made.

The Content and Experience Delivery API has a number of parameters that you can use to limit the number of REST calls you need to make.

The parameters are limit, expand, fields and links.

Limit is the easiest one to understand. When searching for items this parameter limits the number of items returned. The default value is 100. If your client needs a larger number of items returned you can, instead of paging by using the offset parameter and by making a second call for the next page of results, up this number and get more results. Use this only if your client can handle and has use for this larger number of returned items and this does increase the payload size and thus takes more time to download the full set of results.

The seconds parameter I would like to discuss is the links parameter. As each response includes HATEOS links to further explore the API, these links are overhead if your client understands the API well. If you set links=none no additional links are returned, reducing the payload size. Setting links=self only returns the link to the item itself.

The third parameter I want to introduce is the fields parameter. When searching for content items this parameter lists the number of fields that are returned. By default, only the name and description fields are returned. The id and type fields are always returned.

When &fields=updatedDate is appended to the search URL, only the updatedDate is returned. The fields argument is a comma separated value list, so if you want to return multiple fields you can list them by separating the fields with a comma: fields:name,updatedDate.

If you want to add your custom fields you need to prefix the field name with 'fields.'. For instance if your content type has a field with the name career_next_role_skills , you can ask for this field by adding fields=fields.career_next_role_skills.

The fields parameter has one special value: all. This returns all the fields of your content type.

There is are two caveats with this: the fields can only be used when the type is specified. And secondly: fields=all does not return values for largetext, json or location datatypes. If you need to use these types, you have to load the individual item.

The last parameter expand works only on the individual item REST call. It includes the referenced content items and digital assets inline. This has the advantage that when you request the individual item, you can ask for the referenced data in that same call. This can potentially greatly reduce the number of REST calls, again at the expense of a larger initial payload.

As with the fields parameter it uses the 'fields.' prefix for custom fields, you can append them by separating them with a comma and the special 'all' values also works.

As I have shown you, with these 4 parameters you can easily reduce the number of REST calls to get to the content for your application.