APIs
←Overview · Index↑ · APIs - Common Keys→
This document covers common aspects of the following three APIs:
API Specifications
The Node, Registration and Query APIs are specified using:
- The following sub-sections describing common API properties.
- RAML documents and JSON schemas in the APIs folder.
Examples of JSON format output are provided in the examples folder.
API Validation
JSON schemas are included with the RAML API definitions. These include validation for values used within the APIs. It is strongly recommended that implementers of a Registration API use these JSON schemas as part of a validation stage when receiving registrations from Nodes. Invalid resources should cause a 400 HTTP error (Bad Request) to be returned to the client.
Content Types
All APIs MUST provide a JSON representation signalled via ‘Content-Type: application/json’ headers. This SHOULD be the default content type in the absence of any requested alternative by clients. Other content types (such as HTML) are permitted if they are explicitly requested via Accept headers.
API Paths
All NMOS APIs MUST use a path in the following format. Other HTTP resources MAY be presented on the same port by the Node, provided all NMOS resources are available from the /x-nmos/ path as follows:
http(s)://<ip address or hostname>:<port>/x-nmos/<api type>/<api version>/
At each level of the API from the base resource upwards, the response SHOULD include a JSON format array of the child resources available from that point.
Versioning
All public APIs are versioned as follows:
- Requesting the API base resource (such as http(s)://<ip address or hostname>:<port>/x-nmos/query/) will provide a list containing the versions of the API present on the node.
Common API Base Resource
[
"v1.0/",
"v2.0/",
"v3.0/"
]
- Appending /v1.0/ to the API base resource will request version 1.0 of the API if available.
- The versioning format is v<#MAJOR>.<#MINOR>
- MINOR increments SHOULD be performed for non-breaking changes (such as the addition of attributes in a response)
- MAJOR increments MUST be performed for breaking changes (such as the renaming of a resource or attribute)
- Versions MUST be represented as complete strings. Parsing MUST proceed as follows: separate into two strings, using the point (.) as a delimiter. Compare integer representations of MAJOR, MINOR version (such that v1.12 is greater than v1.5).
- Clients are responsible for identifying the correct API version they require.
URLs: Approach to Trailing Slashes
- If a client performs a GET or HEAD request it SHOULD correctly handle a 301 response (moved permanently).
- The client MUST follow the 301 redirect in order to retrieve the required resource.
Error Codes & Responses
The NMOS APIs use HTTP status codes to indicate success, failure and other cases to clients as per RFC 7231 and related standards. Where the RAML specification of an API specifies explicit response codes it is expected that a client will handle these cases in a particular way. As explicit handling of every possible HTTP response code is not expected, clients must instead implement more generic handling for ranges of response codes (1xx, 2xx, 3xx, 4xx and 5xx). For HTTP codes 400 and upwards, a JSON format response MUST be returned as follows:
Example Error Response
{
"code": 400,
"error": "Human readable message which is suitable for user interface display, and helpful to the user",
"debug": "Programmer / debugging detail or traceback"
}
In the above example, the ‘code’ should always match the HTTP status code. ‘error’ must always be present and in string format. ‘debug’ may be null if no further debug information is available.
Further details on when APIs will respond with particular codes is covered in the Behaviour section.