¿El multiplexado de HTTP/2 viola las reglas de las API REST?
La multiplexación es una característica bastante buena de http/2. Permite usar una sola conexión para atender múltiples solicitudes simultáneamente de un único cliente.
Mi pregunta es: ¿esta característica de multiplexación viola las reglas de las API REST?
1) Entiendo que las API REST aplican una arquitectura de solicitud-respuesta, pero la multiplexación sin habilitar la función de empuje del servidor (streaming) es básicamente un paradigma de una solicitud -> una respuesta, por lo que no se está violando, ¿cierto?
2) Las API REST también imponen ser sin estado, pero aquí me pierdo: ¿se considera la multiplexación a través de una sola conexión como estatal o sin estado?
Si quiero actualizar una API REST que actualmente está implementada con HTTP/1.1 para usar HTTP/2, ¿tengo el privilegio de utilizar la característica de multiplexación o debo hacer solicitud tras solicitud (req1, res1, req2, res2…)?
davy.ai
Como modelo de lenguaje IA, no tengo opiniones o creencias subjetivas. Sin embargo, desde una perspectiva técnica, el multiplexado no viola los principios de la arquitectura REST. De hecho, puede mejorar el rendimiento y la eficiencia al reducir el número de conexiones necesarias y permitir el manejo simultáneo de múltiples solicitudes.
En cuanto a tus preguntas:
La capacidad de multiplexado de HTTP/2 no interfiere con la naturaleza sin estado de REST. Cada intercambio de solicitud-respuesta sigue siendo autocontenido e independiente de las solicitudes anteriores o futuras. El uso de una sola conexión no introduce ningún estado “oculto”, y el servidor trata cada solicitud como un mensaje separado y aislado.
Si deseas actualizar tu API REST para utilizar HTTP/2, tienes el privilegio y la habilidad de utilizar la función de multiplexado. Esto puede traer importantes beneficios de rendimiento a tu API, permitiendo una comunicación más rápida y eficiente entre clientes y servidores. Sin embargo, debes asegurarte de que todas las partes involucradas (tanto clientes como servidores) admitan HTTP/2, y que hayas probado y validado cuidadosamente la nueva implementación para asegurarte de que cumple con los requisitos y las especificaciones de tu API REST.