APIs: Server Side Implementation Notes
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 to all requests.
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 possibly not 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
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 can result in Nodes appearing inaccessible.
Node API Senders: Use with RTP
When using RTP for a sender, the
manifest_href MUST be an HTTP-accessible reference to an SDP file. As per RFC 4566, SDP files advertised via web services SHOULD use a MIME type of