QueryAPI
This API definition uses RAML 0.8, which is not supported by the shared HTML renderer. The source is shown below.
#%RAML 0.8
# AMWA NMOS Discovery and Registration Specification: Query API
# (c) AMWA 2016
title: Query
baseUri: http://example.api.com/x-nmos/query/{version}
version: v1.1
mediaType: application/json
schemas:
- Node: !include schemas/node.json
Nodes: !include schemas/nodes.json
Device: !include schemas/device.json
Devices: !include schemas/devices.json
Source: !include schemas/source.json
Sources: !include schemas/sources.json
Flow: !include schemas/flow.json
Flows: !include schemas/flows.json
Sender: !include schemas/sender.json
Senders: !include schemas/senders.json
Receiver: !include schemas/receiver.json
Receivers: !include schemas/receivers.json
EmptySchema: !include schemas/empty.json
ErrorSchema: !include schemas/error.json
traits:
- paged:
description: API resource supporting pagination of results
queryParameters:
paging.since:
description: Return only the results which have been created/updated since the time specified (non-inclusive) (seconds:nanoseconds)
type: string
pattern: "^[0-9]+:[0-9]+$"
paging.until:
description: Return only the results which were created/updated up until the time specified (inclusive) (seconds:nanoseconds)
type: string
pattern: "^[0-9]+:[0-9]+$"
paging.limit:
description: Restrict the response to the specified number of results. Implementations may specify their own default and maximum for the limit
type: integer
paging.order:
description: Specify whether paging should be based upon initial resource creation time, or when it was last modified. In both cases the response should be provided in descending order
type: string
enum: ["create", "update"]
default: "update"
responses:
200:
headers:
Link:
description: Provides references to cursors for paging. The 'rel' attribute may be one of 'next', 'prev', 'first' or 'last'
type: string
example: <http://example.api.com/x-nmos/query/v1.1/nodes/?paging.since=1441716353:6839634&paging.limit=20>; rel="next", <http://example.api.com/x-nmos/query/v1.1/nodes/?paging.until=1441716120:318744030&paging.limit=20>; rel="prev"
X-Paging-Limit:
description: Identifies the current limit being used for paging. This may not match the requested value if the requested value was too high for the implementation
type: integer
X-Paging-Since:
description: Identifies the current value of the query parameter 'paging.since' in use, or if not specified identifies what value it would have had to return this data set. This value may be re-used as the paging.until value of a query to return the previous page of results. Combining this with the X-Paging-Until header value provides the absolute time bounds of the current returned data set.
type: string
example: 1441716353:6839634
X-Paging-Until:
description: Identifies the current value of the query parameter 'paging.until' in use, or if not specified identifies what value it would have had to return this data set. This value may be re-used as the paging.since value of a query to return the next page of results. Combining this with the X-Paging-Since header value provides the absolute time bounds of the current returned data set.
type: string
example: 1441716120:318744030
- downgrade:
description: API resource supporting the return of data which matches an older minor API version than the request would return by default.
queryParameters:
query.downgrade:
description: Minimum API version to return resources from if they exists within the registry
type: string
pattern: "^v[0-9]+.[0-9]+$"
responses:
400:
description: The requested downgrade query moves between major API versions which is not permitted.
- rql:
description: This resource MAY support advanced query formats using the Resource Query Language (RQL) syntax
queryParameters:
query.rql:
description: RQL format string indicating the query to be performed, such as 'and(eq(format,urn:x-nmos:format:video),in(tags.location,(Salford,London)))'. Strings used as filter values MUST be URL encoded.
type: string
responses:
400:
description: The server refuses to perform the query as it would be too resource intensive.
501:
description: The query parameters specified are not currently supported by this implementation.
- ancestry:
description: This resource MAY support ancestry tracking whereby an ID is traced through 'parents' attributes to find and return all related resources
queryParameters:
query.ancestry_id:
description: UUID of the Source or Flow for which the ancestry is to be tracked
type: string
pattern: "^[0-9a-f]{8}-[0-9a-f]{4}-[1-5][0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$"
query.ancestry_type:
description: The type of ancestry query to perform, whether searching for 'parents' or 'children' of the specified resource
type: string
enum: ["parents", "children"]
query.ancestry_generations:
description: The maximum number of generations to search through before returning the set of results. If this is not set, the server may use a default or fail to return results due to the request being too resource intensive
type: integer
responses:
200:
headers:
X-Ancestry-Generations:
description: Identifies the number of ancestry generations being searched through. If 'query.ancestry_generations' is not specified by the user this should be returned as the server defined default.
type: integer
400:
description: The server refuses to perform the query as it would be too resource intensive.
501:
description: The query parameters specified are not currently supported by this implementation.
documentation:
- title: Overview
content: |
The Query API is exposed by NMOS discovery Nodes. It is used to expose the contents of the (distributed) registry to all Nodes on the network. In smaller deployments where no such registry is available, Nodes with their own control capabilities fall back to interrogating Nodes directly using the Peer to Peer specification. This is a Read Only API.
Attributes defined as 'Optional' MUST be returned by the Query API if they exist within the registry. The presence declaration relates more to whether it is required for them to be registered at the Registration API side, or presented via the Node API.
- title: DNS-SD Advertisement
content: |
Query APIs MUST produce an mDNS advertisement of the type \_nmos-query.\_tcp. This MAY be accompanied by a unicast DNS announcement of the same type.
The IP address and port of the Query API MUST be identified via the DNS-SD advertisement, with the full HTTP path then being resolved via the standard NMOS API path documentation.
Multiple DNS-SD advertisements for the same API are permitted where the API is exposed via multiple ports and/or protocols.
- title: DNS-SD TXT Records
content: |
**api\_proto**
The DNS-SD advertisement MUST be accompanied by a TXT record of name 'api\_proto' with a value of either 'http' or 'https' dependent on the protocol in use by the Query API web server.
**api\_ver**
The DNS-SD advertisement MUST be accompanied by a TXT record of name 'api\_ver'. The value of this TXT record is a comma separated list of API versions supported by the server. For example: 'v1.0,v1.1,v2.0'. There should be no whitespace between commas, and versions should be listed in ascending order.
**pri**
The DNS-SD advertisement MUST include a TXT record with key 'pri' and an integer value. Servers MAY additionally represent a matching priority via the DNS-SD SRV record 'priority' and 'weight' as defined in RFC 2782. The TXT record should be used in favour to the SRV priority and weight where these values differ in order to overcome issues in the Bonjour and Avahi implementations.
Values 0 to 99 correspond to an active NMOS Query API (zero being the highest priority). Values 100+ are reserved for development work to avoid colliding with a live system.
- title: Websockets
content: |
Persistent connections to the Query API are supported via Websockets which can be set up via the /subscriptions resource. Query APIs may additionally support the HTTP 'Upgrade' header sent by clients to upgrade an HTTP GET request to a Websocket. In cases where this is performed, a corresponding entry in /subscriptions must also be created with matching query parameters.
- title: Versioning
content: |
A Query API may support multiple API versions at one time, provided data exposed from each of these versioned endpoints matches the schema for that API version. See the [APIs](../docs/2.0. APIs.md) and [Upgrade Path](../docs/6.0. Upgrade Path.md) documentation for more details.
- title: Query Parameters
content: |
As a Query API may provide access to many thousands of resources, query parameters provide the means to narrow down these results. Any attribute which may be returned by a particular API resource SHOULD be available to use as a query parameter, however this RAML documentation only explicitly identifies core attributes under 'queryParameters'.
For a full description of the expected querying behaviour along with examples, please see the [Query Parameters Documentation](../docs/2.5. APIs - Query Parameters.md).
Basic Queries and Downgrade Queries SHOULD be supported. Advanced queries using RQL, ancestry tracking and similar MAY be supported.
** Basic Queries **
Basic queries make use of standard HTTP GET query parameters in the form '?key=value'. Keys may match any attribute which the API schemas indicate could be returned by a given resource.
* Querying Within Objects
Querying using attributes of objects is permitted via the use of a '.' separator. For example, the /receivers resource may be queried with '?subscription.sender_id=2683ad14-642f-459d-a169-ef91c76cec6b'.
* Querying Within Arrays
Querying using attributes of objects held within arrays is permitted via the use of a '.' separator. For example, the /nodes resource may be queried with '?services.type=urn:x-manufacturer:service:tally'. More advanced queries within arrays may require use of the Resource Query Language 'in()' operator.
** Downgrade Queries **
In order to streamline upgrades from one API version to another a Query API may sit in front of a registry which holds registered data matching multiple API versions' schemas. By default the Query API must only return data matching the API version specified in the request URL, however the client may choose to request mixed versions of data if it is capable of handling the potential missing keys.
Downgrades MUST only be performed between minor API versions as major versions may remove or re-purpose attributes. Clients which support multiple major API versions should retrieve this data via multiple HTTP requests or websocket subscriptions.
** Resource Query Language **
Given the constraints of using a standard '?variable=value&variable2=value2' query syntax, Query APIs MAY support Resource Query Language (https://github.com/persvr/rql/) in order to support more advanced queries.
RQL should be formatted in the normalised form as opposed to using FIQL syntax, and passed via the query string using '?query.rql=...'.
Querying within objects and arrays should be performed as in the Basic Queries case by using the '.' separator.
When an RQL query is specified, the Basic Queries format MAY be ignored in order to simplify implementation.
Note that as RQL permits the definition of very complex queries, the server may return a 400 error code to indicate that it is refusing to action the client's request due to the query's complexity.
* Constraints
Not all RQL operators will be suitable for use with a Query API. It is suggested that the following operators are supported, however these are not mandated and implementations may choose to support their own subset.
1) Functions: in(), out(), sort(), like(), select()
2) Logical Operators: and(), or(), not()
3) Relational Operators: eq(), ne(), gt(), ge(), lt(), le()
NB: It is suggested that limit() is not implemented as paging and associated limits is specified directly by the Query API.
** Querying Ancestry **
Sources and Flows list their 'parents' in an array. A Query API implementing ancestry tracking may be queried using '?query.ancestry_...' parameters in order to identify parents or children of a given Source or Flow.
/:
displayName: Base
get:
description: List of paths available from this API
body:
schema: EmptySchema
responses:
200:
body:
example: !include ../examples/queryapi-v1.1-base-get-200.json
schema: !include schemas/queryapi-base.json
/nodes:
displayName: Nodes
get:
is: [paged, rql, downgrade]
description: |
List Nodes.
NB: Query parameters should be implemented for all permitted resource attributes.
body:
schema: EmptySchema
queryParameters:
id:
version:
label:
description:
tags:
responses:
200:
body:
example: !include ../examples/queryapi-v1.1-nodes-get-200.json
schema: Nodes
/{nodeId}:
uriParameters:
nodeId:
type: string
pattern: "^[0-9a-f]{8}-[0-9a-f]{4}-[1-5][0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$"
get:
is: [downgrade]
description: Get a single Node
body:
schema: EmptySchema
responses:
200:
body:
example: !include ../examples/queryapi-v1.1-nodeid-get-200.json
schema: Node
404:
description: Returned when the requested Node ID does not exist
body:
schema: ErrorSchema
/sources:
displayName: Sources
get:
is: [paged, rql, ancestry, downgrade]
description: |
List Sources.
NB: Query parameters should be implemented for all permitted resource attributes.
body:
schema: EmptySchema
queryParameters:
id:
version:
label:
description:
tags:
responses:
200:
body:
example: !include ../examples/queryapi-v1.1-sources-get-200.json
schema: Sources
/{sourceId}:
uriParameters:
sourceId:
type: string
pattern: "^[0-9a-f]{8}-[0-9a-f]{4}-[1-5][0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$"
get:
is: [downgrade]
description: Get a single Source
body:
schema: EmptySchema
responses:
200:
body:
example: !include ../examples/queryapi-v1.1-sourceid-get-200.json
schema: Source
404:
description: Returned when the requested Source ID does not exist
body:
schema: ErrorSchema
/flows:
displayName: Flows
get:
is: [paged, rql, ancestry, downgrade]
description: |
List Flows.
NB: Query parameters should be implemented for all permitted resource attributes.
body:
schema: EmptySchema
queryParameters:
id:
version:
label:
description:
tags:
responses:
200:
body:
example: !include ../examples/queryapi-v1.1-flows-get-200.json
schema: Flows
/{flowId}:
uriParameters:
flowId:
type: string
pattern: "^[0-9a-f]{8}-[0-9a-f]{4}-[1-5][0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$"
get:
is: [downgrade]
description: Get a single Flow
body:
schema: EmptySchema
responses:
200:
body:
example: !include ../examples/queryapi-v1.1-flowid-get-200.json
schema: Flow
404:
description: Returned when the requested Flow ID does not exist
body:
schema: ErrorSchema
/devices:
displayName: Devices
get:
is: [paged, rql, downgrade]
description: |
List Devices.
NB: Query parameters should be implemented for all permitted resource attributes.
body:
schema: EmptySchema
queryParameters:
id:
version:
label:
description:
tags:
responses:
200:
body:
example: !include ../examples/queryapi-v1.1-devices-get-200.json
schema: Devices
/{deviceId}:
uriParameters:
deviceId:
type: string
pattern: "^[0-9a-f]{8}-[0-9a-f]{4}-[1-5][0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$"
get:
is: [downgrade]
description: Get a single Device
body:
schema: EmptySchema
responses:
200:
body:
example: !include ../examples/queryapi-v1.1-deviceid-get-200.json
schema: Device
404:
description: Returned when the requested Device ID does not exist
body:
schema: ErrorSchema
/senders:
displayName: Senders
get:
is: [paged, rql, downgrade]
description: |
List Senders.
NB: Query parameters should be implemented for all permitted resource attributes.
body:
schema: EmptySchema
queryParameters:
id:
version:
label:
description:
tags:
responses:
200:
body:
example: !include ../examples/queryapi-v1.1-senders-get-200.json
schema: Senders
/{senderId}:
uriParameters:
senderId:
type: string
pattern: "^[0-9a-f]{8}-[0-9a-f]{4}-[1-5][0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$"
get:
is: [downgrade]
description: Get a single Sender
body:
schema: EmptySchema
responses:
200:
body:
example: !include ../examples/queryapi-v1.1-senderid-get-200.json
schema: Sender
404:
description: Returned when the requested Sender ID does not exist
body:
schema: ErrorSchema
/receivers:
displayName: Receivers
get:
is: [paged, rql, downgrade]
description: |
List Receivers.
NB: Query parameters should be implemented for all permitted resource attributes.
body:
schema: EmptySchema
queryParameters:
id:
version:
label:
description:
tags:
responses:
200:
body:
example: !include ../examples/queryapi-v1.1-receivers-get-200.json
schema: Receivers
/{receiverId}:
uriParameters:
receiverId:
type: string
pattern: "^[0-9a-f]{8}-[0-9a-f]{4}-[1-5][0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$"
get:
is: [downgrade]
description: Get a single Receiver
body:
schema: EmptySchema
responses:
200:
body:
example: !include ../examples/queryapi-v1.1-receiverid-get-200.json
schema: Receiver
404:
description: Returned when the requested Receiver ID does not exist
body:
schema: ErrorSchema
/subscriptions:
displayName: Subscriptions
post:
description: Create a websocket subscription to an API resource
body:
example: !include ../examples/queryapi-v1.1-subscriptions-post-request.json
schema: !include schemas/queryapi-subscriptions-post-request.json
responses:
201:
body:
example: !include ../examples/queryapi-v1.1-subscriptions-post-200.json
schema: !include schemas/queryapi-subscription-response.json
200:
body:
example: !include ../examples/queryapi-v1.1-subscriptions-post-200.json
schema: !include schemas/queryapi-subscription-response.json
400:
description: Returned when the POST request is incorrectly formatted or missing mandatory attributes
body:
schema: ErrorSchema
get:
is: [paged]
description: List active connections to websockets providing real-time updates on resource changes
body:
schema: EmptySchema
responses:
200:
body:
example: !include ../examples/queryapi-v1.1-subscriptions-get-200.json
schema: !include schemas/queryapi-subscriptions-response.json
/{subscriptionId}:
uriParameters:
subscriptionId:
type: string
pattern: "^[0-9a-f]{8}-[0-9a-f]{4}-[1-5][0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$"
get:
description: Get a single subscription
body:
schema: EmptySchema
responses:
200:
body:
example: !include ../examples/queryapi-v1.1-subscriptionid-get-200.json
schema: !include schemas/queryapi-subscription-response.json
404:
description: Returned when the requested Subscription ID does not exist
body:
schema: ErrorSchema
delete:
description: Delete a single subscription
body:
schema: EmptySchema
responses:
204:
description: The expected response, indicating 'No Content' following the DELETE
403:
description: Returned when a DELETE request is made against a non-persistent subscription which is managed by the Query API and cannot be deleted
body:
schema: ErrorSchema
404:
description: Returned when the requested Subscription ID does not exist
body:
schema: ErrorSchema