Reglas de solicitud/respuesta

solicitudes integridad todas las entidades y estructuras enviadas al servidor en el cuerpo de la solicitud post/put deben contener todas las propiedades documentadas independientemente de si sus valores son necesarios los valores desconocidos y opcionales pueden ser "null" o "0", pero deben especificarse explícitamente en la respuesta, el servidor también siempre enviará estructuras completas para que el cliente no tenga que comprobar la presencia de cada propiedad antes de leerla valores los valores reales en las solicitudes deben coincidir estrictamente con los tipos de datos de las propiedades tenga en cuenta que algunas propiedades aceptan valores nulos, mientras que otras siempre requieren un valor específico que coincida con sus tipos de datos puede encontrar esa información en la sección de definiciones de tipos de datos de cada especificación de versión principal de la api estructuras de solicitudes de datos cada solicitud de datos de la api rest de bsn debe contener el encabezado http "accept" y enumerar únicamente las representaciones de contenido compatibles con el cliente se aceptan valores como " " y "application ", pero producen un resultado aleatorio de la lista de representaciones compatibles con el servidor, que también puede cambiar de vez en cuando, de acuerdo con rfc7231#section 3 4 https //datatracker ietf org/doc/html/rfc7231#section 3 4 por ejemplo, para la mayoría de los métodos debe introducir algo como aceptar application/json, application/vnd bsn error+json en lugar de aceptar / porque aceptar / es ambiguo cada solicitud de datos de la api rest de bsn también puede contener un encabezado http "accept encoding" con la lista de algoritmos de compresión de tráfico compatibles con el cliente, y esperar tráfico sin comprimir o comprimido mediante el algoritmo especificado en el encabezado http de respuesta "content encoding", de acuerdo con rfc7231 https //datatracker ietf org/doc/html/rfc7231 solicitudes condicionales las apis rest de brightsign bsn admiten solicitudes condicionales en todos los métodos singulares de recuperación, edición y eliminación de entidades (por ejemplo, put, delete, patch) debe usar solicitudes condicionales cuando se esperan múltiples recuperaciones de la misma entidad y especialmente en las solicitudes de actualización y eliminación de una sola entidad estas se implementan de acuerdo con rfc2616 https //datatracker ietf org/doc/html/rfc2616 en el lado del servidor y se basan en los encabezados http "last modified", "if modified since" e "if unmodified since" compresión la compresión de tráfico para las solicitudes de la api rest de bsn también puede implementarse bajo demanda, pero este caso no se describe en rfcstandards https //www rfc editor org/standards es una buena práctica especificar el encabezado "accept encoding" al formular la solicitud al servidor para que este pueda comprimir la respuesta cuando sea razonable (cuando su tamaño supere los 800 bytes) los algoritmos de compresión compatibles son gzip y deflate respuestas brightsign utiliza códigos de respuesta http estándar para comunicar el éxito o el fallo de las solicitudes de api xml es el formato de respuesta predeterminado el formato json se devolverá si especifica el encabezado http de solicitud aceptar application/json