Considerations¶
The following are some general considerations about this API that must be taken into account before consuming the service.
Compatibility¶
This service exposes a RESTful API designed to be backwards-compatible (whenever possible). An API is said to be backwards-compatible if a client written against a previous version of the API will keep working against future ones.
The following changes are considered backwards compatible:
- Adding new resources (on new URIs)
- Adding new optional request form fields or JSON properties
- Adding new optional query parameters
- Adding new JSON properties to existing API responses
- Changing the order of JSON properties on existing API responses
- Changing the order of items on JSON object or array properties (unless the documentation states they are ordered)
- Adding new optional headers in requests
- Adding new headers in responses
The following changes are considered backwards incompatible (breaking changes):
- Removing API resources
- Renaming API resources (changing URIs)
- Adding new required request form fields, JSON properties, query parameters or headers
- Making any existing optional request form fields, JSON properties, query parameters or headers required
- Removing existing request form fields, JSON properties, query parameters or headers
- Changing the meaning of existing request form fields, JSON properties, query parameters or headers
- Adding new request form fields, JSON properties, query parameters or headers that alter the meaning of existing ones
- Changing the type of existing request form fields or JSON properties (from string to number for example)
- Changing the format or maximum length of existing opaque string properties with documented conflicting constraints
Backwards incompatible (breaking) changes may be introduced by bumping the API version, as explained on the Versioning section. In this scenario, previous versions of the API may be marked as deprecated and stop receiving new features. Should this happen, these old versions will be available for some agreed period of time, until they are eventually removed.
Veridas will announce in advance this deprecation and removal process (also called sunsetting) to ensure that users have enough time to migrate to the newest version of the API without causing any downtime or service disruptions.
Authentication¶
This service sits behind a gateway responsible for authenticating end users and routing requests. The authentication method is API key based.
IP restriction¶
For security reasons, to ensure that XpressID is embedded just on those machines or servers which are allowed to do so, the production or LIVE environment includes a whitelist which contains the machines or servers IPs where the service is allowed to be embedded. For this reason, production machines IPs must be sent to Veridas to be included in the whitelist. Otherwise, the connection to the authentication API will be blocked.
Requests¶
- The application/json content type must be used on every request when a request body is required.
- The API is HTTP-based and uses SSL everywhere with valid certificates. For security reasons, customers should never trust VeriSaaS endpoints exposing invalid certificates
- Endpoints attempt to conform to the design principles of Representational State Transfer (REST).
- The service includes an/alive endpoint that returns the 204 HTTP status code if the service is up and running. This can be used to check the service’s health.
In general, API responses are encoded using JSON, regardless of the accepted content-type specified by the client. Also, certain responses like the ones regarding the files (images, videos, etc.) retrieval, are just the binary of the file itself. Responses will return a suitable HTTP status code indicating if the request was successful (200, 201 or 204 if nothing else is returned) or not (any other code). Responses will also include a code field in the JSON body that can provide more information about the concrete error on each case.
In general, successful responses will have the following format:
HTTP Status: 200 OK
{
"data": {
DATA
}
}
or
HTTP Status: 204 NO CONTENT
where:
Field | Required | Description |
---|---|---|
data | no | Message payload. It will contain an arbitrary JSON content defined by each endpoint. |
In case of error:
Field | Required | Description |
---|---|---|
code | yes | Error code |
message | no | A message indicating what went wrong |
errors | no | A list of errors just in case. This is a list containing the fields "field", "code" and "message". "field" is optional. |
Example:
{
"code": "InvalidInputParameter",
"message": "Data field contains invalid JSON"
}
Versioning¶
As for now, the API version will not be included in the URL. If this changes, this will appear after the base url and before the endpoint:
https://<base_url>/<service>/v{number:integer}/<endpoint>
Non backwards compatible changes will cause a version increment.