La negociación de contenido (Content Negotiation) es el mecanismo de la comunicación HTTP por el cual el cliente (navegador) y el servidor acuerdan la representación más adecuada del recurso solicitado. Permite que una misma URL devuelva contenido diferente en función del idioma del usuario, su dispositivo o los formatos que soporta.
La negociación se realiza principalmente a través de las cabeceras de la solicitud HTTP. Las más representativas son Accept (tipos de medio soportados: text/html, application/json, etc.), Accept-Language (idiomas preferidos: ja, en-US, etc.) y Accept-Encoding (métodos de compresión soportados: gzip, br, etc.). Todas ellas admiten valores q para indicar preferencia: Accept-Encoding: br, gzip;q=0.8 pide br en primer lugar y acepta gzip si no está disponible. Cuando el servidor cambia su respuesta según esas cabeceras, debe nombrarlas en la cabecera Vary. Si se olvida Vary: Accept-Language, una caché o una CDN entregará al resto de visitantes el primer idioma que le llegó.
En sitios multilingues, la negociación de contenido guarda una relación estrecha con las URL acortadas. Es posible implementar que una misma URL acortada redirija a la versión en japonés o en inglés según la configuración de idioma del navegador del usuario. Sin embargo, desde el punto de vista del SEO, es preferible que cada idioma tenga su propia URL y que se vinculen mediante etiquetas hreflang. La negociación de contenido basada en idioma puede impedir que los motores de búsqueda indexen correctamente cada versión lingüística. Google también recomienda preparar una URL distinta para cada versión lingüística en lugar de cambiar la presentación según las cookies o la configuración del navegador, y pide evitar que los visitantes sean redirigidos de forma automática de una versión a otra, porque esas redirecciones pueden impedir que tanto las personas como los motores de búsqueda lleguen a todas las versiones. Su rastreador, además, envía las peticiones sin la cabecera Accept-Language, de modo que un sitio que decide solo con ella deja a la vista únicamente su idioma predeterminado. Adaptar el contenido a partir de la IP tampoco es una práctica aconsejada.
En el diseño de API, la negociación de contenido también es fundamental. Es habitual que la API de un servicio de URL acortadas devuelva la respuesta en JSON o XML según la cabecera Accept. Ofrecer varias representaciones de un mismo recurso permite que cada cliente elija el formato que sabe manejar. El algoritmo que decide entre ellas no está definido en HTTP, sino que queda en manos de la implementación del servidor. También es una decisión de la implementación si un formato no soportado se responde con 406 (Not Acceptable) o con la representación predeterminada.
Existen dos tipos principales de negociación: la dirigida por el servidor (el servidor decide en función de las cabeceras de la solicitud) y la dirigida por el agente (el servidor presenta las opciones y el cliente elige). La especificación de HTTP llama a la primera proactive negotiation y a la segunda reactive negotiation. En la práctica predomina la primera, a cambio de que toda decisión inferida de las cabeceras resulte en cierta medida arbitraria. La segunda no llegó a extenderse porque el formato de la página que enumera las opciones no está especificado, lo que impide automatizar la elección, y porque añade un viaje de ida y vuelta antes de obtener el recurso real.