Networked Media Open Specifications

APIs: Server Side Implementation Notes

←APIs - Client Side Implementation Notes · Index↑ · APIs - Load Balancing & Redundancy→

Cross-Origin Resource Sharing (CORS)

In order to permit web-based control interfaces to be hosted remotely, all NMOS APIs MUST implement valid CORS HTTP headers in responses, and respond to HTTP pre-flight OPTIONS requests. In order to simplify development, the following headers may be returned in order to remove these restrictions as far as possible. Note that these are very relaxed and may not be suitable for a production deployment.

In addition to this, where highlighted in the API specifications servers MUST respond to HTTP pre-flight OPTIONS requests. Servers MAY additionally support HTTP OPTIONS requests made to any other API resource.

In order to simplify development, the following headers may be returned in order to remove these restrictions as far as possible. Note that these are very relaxed and may not be suitable for a production deployment.

Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, PUT, POST, PATCH, HEAD, OPTIONS, DELETE
Access-Control-Allow-Headers: Content-Type, Accept
Access-Control-Max-Age: 3600

To ensure compatibility, the response ‘Access-Control-Allow-Headers’ could be set from the request’s ‘Access-Control-Request-Headers’.

Use of ‘.local’ Hostnames

Where ‘href’ or ‘host’ attributes are specified in the APIs, it is strongly recommended to use either IP addresses or hostnames which are resolvable using unicast DNS. Whilst ‘.local’ hostnames are convenient in a zero-configuration layer 2 network segment, these are not usually resolvable beyond these boundaries. As this specification is intended for use between layer 3 network segments, use of these hostnames may result in Nodes appearing inaccessible.

←APIs - Client Side Implementation Notes · Index↑ · APIs - Load Balancing & Redundancy→