api - freshdesk sdk apk

API REST con HTTP/2

Question

Hace un par de meses, HTTP / 2 ha sido publicado como RFC7540 . ¿Cómo afectará esto a la API REST existente construida en HTTP / 1.1?

Según wikipedia , HTTP / 2 ha agregado nuevas características. ¿Cómo podemos aprovechar estas nuevas características?

Siéntase libre de mejorar esta pregunta.

Gracias.

Answer 1

El principal beneficio que veo es el Servidor Push para las API RESTful de hipermedia, que contienen referencias a recursos, a menudo URL absolutas dependientes del dominio como /post/12 .

Ejemplo: GET https://api.foo.bar/user/3

{
  "_self": "/user/3"
  "firstName": "John",
  "lastName": "Doe",
  "recentPosts": [
    "/post/3",
    "/post/13",
    "/post/06
    ]
}

HTTP / 2 Push se puede usar para rellenar de forma preventiva el caché del navegador si el servidor sabe que el cliente probablemente querrá realizar ciertas solicitudes GET en el futuro.

En el ejemplo anterior, si HTTP / 2 Server Push está activado y configurado correctamente, podría entregar /post/3 , /post/13 y /post/06 junto con /user/3 . Los GETs sucesivos a una de esas publicaciones darían lugar a respuestas en caché. Además, el borrador del resumen de la memoria caché permitiría al cliente enviar información sobre el estado de su memoria caché, evitando empujones innecesarios. Esto es mucho más práctico para las API controladas por hipermedia que los cuerpos incrustados, como HAL .

Más información sobre las razones aquí: los problemas con la incorporación en REST hoy y cómo podría resolverse con HTTP / 2 .

Answer 2

La especificación HTTP / 2 intencionalmente no introdujo una nueva semántica para el programador de aplicaciones. De hecho, las principales bibliotecas del lado del cliente (NSUrlSession en iOS, OkHttp en Android, React Native, JS en el entorno del navegador) admiten HTTP / 2 de forma transparente para usted como desarrollador.

Debido a la capacidad de HTTP / 2 para multiplexar muchas solicitudes a través de una sola conexión TCP, algunos optimizadores de aplicaciones implementados en el pasado, como el procesamiento por lotes de solicitudes, se vuelven obsoletos e incluso contraproducentes.

La función de empuje probablemente se utilizará para entregar eventos y podrá reemplazar el sondeo y posiblemente los sockets web en algunas aplicaciones.

Una posible aplicación de la función de inserción del servidor en HTTP / 2 a las API REST es la capacidad de acelerar las aplicaciones heredadas en el nivel de proxy inverso al enviar las solicitudes anticipadas al cliente, en lugar de esperar a que lleguen. Es decir, envíe respuestas al perfil de usuario y otras llamadas API comunes justo después de completar la solicitud de inicio de sesión.

Sin embargo, Push aún no se implementa ampliamente en la infraestructura de servidor y cliente.

Answer 3

La semántica principal de HTTP se ha conservado en HTTP / 2. Esto significa que todavía tiene HTTP methods como GET , POST , etc., HTTP headers y URIs para identificar recursos.

Lo que ha cambiado en HTTP / 2 con respecto a HTTP / 1.1 es la forma en que la semántica de HTTP (por ejemplo, "Quiero PUT resource /foo en host domain.com ") se transporta por cable.

En este sentido, las API de REST basadas en HTTP / 1.1 continuarán funcionando de manera transparente como antes, sin que se realicen cambios en las aplicaciones. El contenedor web que ejecuta las aplicaciones se encargará de traducir el nuevo formato de cable a la semántica HTTP habitual en nombre de las aplicaciones, y la aplicación solo verá la semántica HTTP de nivel superior, sin importar si se transportó a través de HTTP / 1.1 o HTTP / 2 sobre el cable.

Debido a que el formato de conexión HTTP / 2 es más eficiente (en particular debido a la multiplexación y la compresión), las API REST sobre HTTP / 2 también se beneficiarán de esto.

La otra mejora importante presente en HTTP / 2, HTTP/2 Push , apunta a la descarga eficiente de recursos correlacionados, y probablemente no sea útil en el caso de uso de REST.

Un requisito típico de HTTP / 2 se implementará a través de TLS. Esto requiere que los implementadores pasen de http a https y configuren la infraestructura necesaria para admitirlo (compre los certificados de una autoridad confiable, renuévelos, etc.).