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 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 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 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 application/sdp.
←APIs - Client Side Implementation Notes · Index↑ · APIs - Load Balancing & Redundancy→