it-swarm.com.de

REST API mit HTTP/2

Vor einigen Monaten wurde HTTP/2 als RFC7540 ..__ veröffentlicht. Wie wirkt sich dies auf die vorhandene REST - API aus, die auf HTTP/1.1 basiert

Gemäß wikipedia hat HTTP/2 neue Funktionen hinzugefügt. Wie können wir diese neuen Funktionen nutzen?

Fühlen Sie sich frei, um diese Frage zu verbessern.

Vielen Dank.

23
Sorter

Die Hauptsemantik von HTTP wurde in HTTP/2 beibehalten. Dies bedeutet, dass es noch HTTP methods wie GET, POST usw., HTTP headers und URIs zum Identifizieren von Ressourcen enthält.

Was sich in HTTP/2 in Bezug auf HTTP/1.1 geändert hat, ist die Art und Weise, in der die HTTP-Semantik (z. B. "Ich möchte PUT resource /foo auf Host domain.com") über die Leitung transportiert wird.

In dieser Hinsicht funktionieren REST - APIs, die auf HTTP/1.1 erstellt wurden, weiterhin transparent wie zuvor, ohne dass Änderungen an Anwendungen vorgenommen werden müssen. Der Webcontainer, der die Anwendungen ausführt, sorgt dafür, dass das neue Drahtformat für die Anwendungen in die gewöhnliche HTTP-Semantik übersetzt wird, und die Anwendung sieht nur die HTTP-Semantik der höheren Ebene, unabhängig davon, ob sie über HTTP/1.1 oder HTTP/transportiert wurde. 2 über dem Draht.

Da das HTTP/2-Kabelformat (insbesondere aufgrund von Multiplexing und Komprimierung) effizienter ist, profitieren auch REST - APIs über HTTP/2.

Die andere wichtige Verbesserung in HTTP/2, HTTP/2 Push, zielt auf das effiziente Herunterladen korrelierter Ressourcen ab und ist in der Verwendung von REST wahrscheinlich nicht nützlich.

Eine typische Anforderung von HTTP/2 ist die Bereitstellung über TLS . Dies erfordert, dass sich die Bereitsteller von http auf https bewegen und die erforderliche Infrastruktur einrichten müssen, um dies zu unterstützen (Kaufen Sie die Zertifikate von einer vertrauenswürdigen Stelle, erneuern Sie sie usw.) .

23
sbordet

Die HTTP/2-Spezifikation hat absichtlich keine neue Semantik für Anwendungsprogrammierer eingeführt. Tatsächlich unterstützen wichtige clientseitige Bibliotheken (NSUrlSession unter iOS, OkHttp unter Android, React Native und JS in Browser-Umgebung) HTTP/2 transparent für Sie als Entwickler.

Aufgrund der HTTP/2-Fähigkeit, viele Anforderungen über eine einzige TCP - Verbindung zu multiplexen, wurden einige in der Vergangenheit implementierte Optimierungsanwendungsentwickler, z. B. request batching , obsolet und sogar kontraproduktiv. 

Die Push-Funktion wird wahrscheinlich zur Bereitstellung von Ereignissen verwendet und kann in einigen Anwendungen Abfragen und möglicherweise Websockets ersetzen.

Eine mögliche Anwendung der Server-Push-Funktion in HTTP/2 auf REST - APIs ist die Fähigkeit, ältere Anwendungen auf der Ebene des umgekehrten Proxys zu beschleunigen, indem erwartete Anforderungen vorab an den Client gesendet werden, anstatt auf deren Eintreffen zu warten. Das heißt Antworten direkt auf das Benutzerprofil und andere allgemeine API-Aufrufe senden, nachdem die Anmeldeanforderung abgeschlossen ist.

Push ist jedoch in der gesamten Server- und Clientinfrastruktur noch nicht umfassend implementiert. 

4
DenisM

Der Hauptvorteil, den ich sehe, ist Server Push für RESTful-APIs für Hypermedia, die Verweise auf Ressourcen enthalten, häufig absolute domänenabhängige URLs wie /post/12.

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

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

HTTP/2 Push kann verwendet werden, um den Browser-Cache vorab zu füllen, wenn der Server weiß, dass der Client in der Zukunft wahrscheinlich bestimmte GET-Anforderungen ausführen möchte.

Wenn im obigen Beispiel HTTP/2 Server Push aktiviert und ordnungsgemäß konfiguriert ist, kann /post/3, /post/13 und /post/06 zusammen mit /user/3..__ an einen dieser Posts übermittelt werden. Nachfolgende GETs führt zu zwischengespeicherten Antworten. Außerdem würde the cache digest draft dem Client das Senden von Informationen über den Cache-Status ermöglichen, wodurch unnötige Pushs vermieden werden. Dies ist für hypermedia-gesteuerte APIs viel praktischer als eingebettete Körper wie HAL .

Weitere Informationen zu den Gründen finden Sie hier: Die Probleme beim Einbetten in REST heute und wie diese mit HTTP/2 gelöst werden könnten.

0
Jules Randolph