Por qué suelo no usar la negociación de contenido

Artículo original ↗ Discusión en Hacker News ↗

Los desarrolladores web están sopesando los beneficios y las desventajas de la negociación de contenido HTTP, especialmente cuando se usa la misma URL para servir tanto HTML para humanos como JSON para máquinas. Muchos abogan por separar los endpoints de “hypermedia” (HTML) de las APIs de datos JSON para evitar mezclar preocupaciones de presentación con interfaces públicas, simplificar el comportamiento de caché/CDN y mantener URLs predecibles, aunque eso signifique renunciar a algunas de las funciones más abstractas de HTTP. Otros señalan que, aunque encabezados como `Accept` y `Vary` pueden gestionar formatos y versionado con elegancia en teoría, en la práctica las herramientas, los CDN y las formas de trabajo del equipo suelen hacer más prácticos los enfoques más simples basados en URL o en parámetros de consulta.

Negociación de contenido: utilidad e inconvenientes

  • Algunos la consideran necesaria en casos limitados: elegir entre JSON/XML, binario frente a JSON, o múltiples formatos de datos (CSV/TSV/Parquet), y en usos de semántica web/datos enlazados, donde el mismo identificador debería servir HTML a los navegadores y JSON-LD/RDF a las bibliotecas.
  • Otros sostienen que es excesiva: JSON domina para los datos, HTML para el contenido, así que la “negociación” añade complejidad con poca ganancia. Muchos clientes no entienden bien los encabezados Accept, y los usuarios reales suelen preferir un simple parámetro de consulta.
  • Varias personas encuentran conceptualmente confuso que la misma URL y el mismo método puedan devolver formatos muy distintos.

URLs, parámetros de consulta y encabezados

  • Muchos prefieren URLs explícitas o parámetros de consulta (/item.json, ?format=json) por ser más fáciles de entender para humanos, visibles en los registros, fáciles con curl y amigables con la caché.
  • Quienes apoyan los encabezados subrayan que Accept está estandarizado, permite preferencias ponderadas y tipos de medios personalizados (incluida la versionado), y evita trucos de URL “tipadas como cadenas”.
  • Sigue el debate sobre la versionado de API: segmentos de ruta como /v1/ se ven como más comunes y visibles; otros prefieren tipos de medios versionados mediante Accept.

CDN, caché y Vary/Accept

  • Varios comentarios señalan que Cloudflare y otros CDN a menudo ignoran Vary (especialmente para contenido que no es imagen), rompiendo la negociación de contenido y haciendo que se sirvan variantes incorrectas desde la caché.
  • Algunos operadores de CDN restringen Vary por razones de rendimiento, huella de caché y distribución de metadatos. Esto empuja a los profesionales a alejarse de la negociación y optar por endpoints separados.

Hypermedia frente a APIs de datos; htmx frente a SPA

  • Muchos coinciden en separar “endpoints de hypermedia/HTML para humanos” de “APIs de datos/JSON para máquinas” para evitar mezclar en las APIs públicas la paginación, la ordenación y preocupaciones específicas de la UI.
  • Se elogia a htmx y a los flujos renderizados en servidor por permitir a los equipos construir la app una sola vez, evitar duplicar lógica en una SPA en JS y añadir comportamiento rico con JavaScript mínimo.
  • Los escépticos dicen que los marcos modernos del lado del cliente (por ejemplo, React+TypeScript) ofrecen mejores patrones, tipado y localización del código para interfaces complejas, y ven los patrones de hypermedia como incómodos para aplicaciones sofisticadas con estado.

¿Qué cuenta como API?

  • Hay desacuerdo sobre la terminología: algunos sostienen que las “APIs de hypermedia” en HTML, fuertemente acopladas, no son realmente APIs para múltiples clientes independientes, sino parte de la aplicación; otros insisten en que el HTML mismo es una API de red para los navegadores.