Page Comparison

...

All requests must be authenticated

Every request to Seamless APIs must be authenticated. For details of the authentication process, please see Authentication.

Use sparse fieldset selection

TBD

Use paging

...

Clients should request only fields that they need from an endpoint. This practice is especially true for resource types that have a lot of fields or have fields with large data such as quotes in the Quotation Service and policies in the Policy Management. For example, the following request retrieves quotes with a sparse fieldset selection specified for the quotes resource. It also specifies the page size, page number, and a sort order.

Code Block
language json
GET {{base-url-sales}}/api/v1/quotes?fields[quotes]=reference,description,period,status&page[size]=10&page[number]=1&sort=-createdDate Authorization: {{access-token}} Accept: application/vnd.api+json

If the client does not specify a sparse fieldset selection for a given resource type, the API may not include fields with large data for that resource type. This behaviour adheres to the specification.

If a client does not specify the set of fields for a given resource type, the server MAY send all fields, a subset of fields, or no fields for that resource type.

For more details of sparse fieldset specification, please refer to https://jsonapi.org/format/1.1/#fetching-sparse-fieldsets

Use paging

Requests for multiple resource instances should include a page size. If a page size is not specified, the default page size of 10 is used.

Do not use obsolete features

TBD

total-records vs totalResources

Sparse fieldset syntax

...

This section describes obsolete features that should not be used and may not be available in future updates to the APIs.

total-records

Responses for a multiple-resources request with pagination may include a total-records item in the meta property, which is the total of resource items match the query parameters. total-records is obsolete and may not be available in future updates of the APIs. Please use the new totalResources instead. For example, the following response include both total-records and totalResources, but again, totalResources should be used instead.

HTTP/2 200 OK
{
  "data": [
    {
      "type": "policies",
      "id": "policy-6f21f713-f977-5ded-a1d0-15d82ee48931",
      "attributes": {
        "reference": "1106467",
        "description": "Sample Customer Name",
        "period": {
          "start": "2024-12-19T00:00:00+00:00",
          "end": "2025-12-18T23:59:59+00:00"
        },
        "currencyCode": "GBP",
        "status": "Created"
      }
    },
    ...
  ],
  "meta": {
    "total-records": 3,
    "totalResources": 3
  }
}

Filter syntax

JSON:API specification v1.1 doesn’t describe a standardized filter syntax. Therefore, the filter syntax varies and depends on the underlying technologies used to develop the APIs. For microservices in the list at the beginning of the Best practices for consuming JSON APIs section, the filter syntax is described in detailed at https://www.jsonapi.net/usage/reading/filtering.html. Please be informed of the following guidelines regarding to the filter syntax:

1. Legacy filters, e.g. ?filter[lastName]=eq:Smith are still supported, but they may be removed in a future update of the services. Any new code should use the new filter syntax, and existing code using legacy filters should be updated to use the new filters.

2. New filters MUST be prefixed with expr:, for example, ?filter=expr:equals(lastName,'Smith').

List of Seamless APIs

...