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 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.
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, PUT, POST, 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.
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 ‘application/sdp’.
←APIs - Client Side Implementation Notes · Index↑ · APIs - Load Balancing & Redundancy→