Request/Response Rules

requests completeness all the entities and structures sent to the server in the post/put request body must contain all documented properties regardless of whether their values are needed unknown and optional values may be either "null" or "0" but must be specified explicitly in response, the server also will always send complete structures so the client doesn't have to check the presence of each property before reading it values the actual values in requests must strictly match the data types in the properties note that some properties are nullable, while others always require a specific value which matches their data types you can find that information in the data type definitions section of each main api version specification data request structures each bsn rest api data request must contain the "accept" http header and list only the content representations that are supported by the client values like " " and "application " are accepted but produce random result from the list of representations supported by the server, which also may change from time to time, according to https //datatracker ietf org/doc/html/rfc7231#section 3 4 for example, for most methods you should enter something like accept application/json, application/vnd bsn error+json instead of accept / because accept / is ambiguous each bsn rest api data request may also contain an "accept encoding" http header with the list of traffic compression algorithms supported by the client, and expect either non compressed or compressed by the algorithm specified in "content encoding" http response header according to https //datatracker ietf org/doc/html/rfc7231 conditional requests brightsign bsn rest apis support conditional requests in all singular entity retrieval editing and removal methods (for example, put, delete, patch) you should use conditional requests when multiple retrievals of the same entity are expected and especially in update and delete requests of a single entity these are implemented according to https //datatracker ietf org/doc/html/rfc2616 on the server side and based on the "last modified", "if modified since" and "if unmodified since" http headers compression traffic compression for bsn rest api requests may also be implemented on demand but this case is not described in https //www rfc editor org/standards it is good practice to specify the “accept encoding” header in forming the server so that it may compress the response when reasonable (when its size exceeds 800 bytes) the supported compression algorithms are gzip and deflate responses brightsign uses standard http response codes to communicate the success or failure of api requests xml is the default response format json format will be returned if you specify the http request header accept application/json