Un paio di mesi fa, HTTP/2 è stato pubblicato come RFC7540. Come influenza l'API REST esistente su HTTP/1.1API REST con HTTP/2
Come da wikipedia, HTTP/2 ha aggiunto nuove funzionalità. Come possiamo noi approfittare di queste nuove funzionalità?
Sentitevi liberi di migliorare questa domanda.
Grazie.
La semantica principale di HTTP è stata mantenuta in HTTP/2. Ciò significa che ha ancora HTTP methods come GET, POST, ecc., HTTP headers e URIs per identificare le risorse.
Cosa è cambiato in HTTP/2 rispetto al HTTP/1.1 è il modo in cui l'HTTP semantica (ad esempio "Voglio PUT risorsa /foo sull'host domain.com") viene trasportato sul filo.
In questa ottica, le API REST create su HTTP/1.1 continueranno a funzionare in modo trasparente come in precedenza, senza modifiche da apportare alle applicazioni. Il contenitore web che esegue le applicazioni si occuperà di tradurre il nuovo formato di filo nella consueta semantica HTTP per conto delle applicazioni e l'applicazione vedrà semplicemente la semantica HTTP di livello superiore, indipendentemente dal fatto che sia stata trasportata via HTTP/1.1 o HTTP/2 sul filo.
Poiché il formato HTTP/2 wire è più efficiente (in particolare a causa del multiplexing e della compressione), anche le API REST sopra HTTP/2 ne trarranno vantaggio.
L'altro miglioramento importante presente in HTTP/2, HTTP/2 Push, si riferisce al download efficiente di risorse correlate e probabilmente non è utile nel caso REST.
Un tipico requisito di HTTP/2 deve essere distribuito su TLS. Ciò richiede ai deployer di passare da http a https e configurare l'infrastruttura richiesta per supportarlo (acquistare i certificati da un'autorità attendibile, rinnovarli, ecc.).
Le specifiche HTTP/2 non hanno introdotto intenzionalmente una nuova semantica per il programmatore di applicazioni. Infatti, le principali librerie lato client (NSUrlSession su iOS, OkHttp su Android, React Native, JS in ambiente browser) supportano HTTP/2 in modo trasparente come sviluppatore.
A causa della capacità HTTP/2 di multiplexare molte richieste su una singola connessione TCP, alcuni sviluppatori di applicazioni di ottimizzazione implementati in passato, come request batching, diventerebbero obsoleti e addirittura controproducenti.
La funzionalità di push verrebbe probabilmente utilizzata per fornire eventi e sarà in grado di sostituire il polling e possibilmente i websocket in alcune applicazioni.
Una possibile applicazione della funzione di push server nelle API HTTP/2 a REST è la capacità di accelerare le applicazioni legacy sul livello di proxy inverso inviando preventivamente le richieste anticipate al client, invece di attendere che arrivino. Cioè spingere le risposte al profilo utente e altre chiamate API comuni subito dopo aver completato la richiesta di accesso.
Tuttavia, Push non è ancora ampiamente implementato sull'infrastruttura server e client.
Suppongo che HTTP/2 introduca alcune nuove semantiche (come Server Push), ma non cambia nessuna delle semantica HTTP/1.x esistente, quindi è retrocompatibile. Pertanto, le applicazioni Web possono essere aggiornate in modo trasparente a HTTP/2. – zeronone
Quindi non è necessario modificare nulla per quanto riguarda l'applicazione web/api?Basta configurarlo sul server (incluso TLS) e funziona bene? – greenhoorn
corretto. Non posso parlare per ogni web server là fuori, ma per Jetty (sono un committer) devi solo configurare Jetty con il modulo 'http2' e sei a posto. – sbordet