--- title: Reglas de solicitud/respuesta slug: develop/es/reglas-de-solicitudrespuesta docTags: createdAt: 2025-03-11T07:03:28.938Z --- # 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*.