REST-API mit HTTP/2

Paar Monaten, HTTP/2 wurde veröffentlicht als RFC7540 .
Wie wird sich dies auf die bestehende REST-API gebaut, die auf HTTP/1.1

Als pro wikipedia, HTTP/2 hat neue Funktionen Hinzugefügt. Wie können wir
nehmen Sie die Vorteile dieser neuen Funktionen nutzen?

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

Dank.

InformationsquelleAutor Sorter | 2015-07-29
  1. 23

    Die wichtigsten semantischen HTTP beibehalten wurde in HTTP/2. Dies bedeutet, dass es immer noch HTTP methods wie GET, POST usw., HTTP headers, und URIs zu identifizieren Ressourcen.

    Was hat sich geändert in HTTP/2 mit Bezug zu HTTP/1.1 ist die Art und Weise der HTTP-Semantik (z.B. "ich möchte PUT Ressource /foo auf host domain.com") transportiert wird, über den Draht.

    In diesem Licht, REST-APIs gebaut auf HTTP/1.1 wird weiterhin die Arbeit transparent wie zuvor, keine änderungen an den Anwendungen. Der web-container läuft, dass die Programme kümmern sich um die Umsetzung der neuen Draht-format in den üblichen HTTP semantischen auf die Namen der Anwendungen und die Anwendung sieht nur die höhere Ebene, HTTP semantic, egal, ob es dabei transportiert über HTTP/1.1 oder HTTP/2 über den Draht.

    Weil der HTTP/2-Draht-format ist effizienter (insbesondere durch multiplexing und Kompression), REST APIs, die oberhalb von HTTP/2 wird auch der nutzen dieser.

    Den anderen großen Verbesserung vorhanden, die in HTTP/2, HTTP/2 Push Ziele, effizientes laden von Ressourcen korreliert, und es ist wahrscheinlich nicht sinnvoll in den REST Anwendungsfall.

    Einer typischen Anforderung von HTTP/2 eingesetzt werden über TLS.
    Diese benötigen Anwender, um von http zu https und Einrichtung der erforderlichen Infrastruktur zu unterstützen, dass (kaufen Sie die Zertifikate von einer vertrauenswürdigen Zertifizierungsstelle, erneuern, etc.).

    • So dass Sie nicht haben, etwas zu ändern in Bezug auf die web-Anwendung / api? Nehmen Sie die Konfiguration auf dem server (einschließlich TLS) und es funktioniert richtig?
    • Richtig. Ich kann nicht sprechen für alle web-server gibt, aber für Jetty (ich bin ein committer), die Sie gerade konfigurieren, Jetty mit der http2 - Modul und Sie sind gut zu gehen.
    • Es ist eine wortgetreue Kopie dieser in einem DZone Artikel von einem Autor namens Guy Levin: dzone.com/articles/benefits-of-rest-apis-with-http2#20 (oder ist es die andere Weise herum, schaut sich die Termine hier...)
    • danke! Ich kontaktierte den Autor.
    InformationsquelleAutor sbordet
  2. 4

    HTTP/2 spec absichtlich nicht in der Einführung neuer Semantik für die Anwendung Programmierer. In der Tat, major-client-side-Bibliotheken (NSUrlSession auf iOS, OkHttp auf Android, Reagieren Nativen, JS im browser-Umfeld) Unterstützung von HTTP/2 transparent für Sie als Entwickler.

    Durch HTTP/2 die Fähigkeit zum multiplexbetrieb viele Anfragen über eine einzige TCP-Verbindung, einige Optimierungen Anwendungsentwickler implementiert in der Vergangenheit, wie Batchverarbeitung werden würde, die überflüssig und sogar kontraproduktiv.

    Push-Funktion würde wahrscheinlich verwendet werden, um Ereignisse liefern-und wird in der Lage sein zu ersetzen, polling und möglicherweise websockets in einigen Anwendungen.

    Eine mögliche Anwendung von server-push-feature, in HTTP/2-REST-APIs ist die Fähigkeit, zu beschleunigen legacy-Anwendungen auf d.h. die reverse-proxy-Ebene durch drücken der zu erwartenden Anforderungen vor der Zeit an den client, anstatt zu warten, für Sie zu kommen. I. e. push-Antworten auf user-Profil, und anderen common-API-Aufrufe direkt nach dem login Anforderung abgeschlossen ist.

    Aber Push ist noch nicht überall umgesetzt, über server-und client-Infrastruktur.

    • Ich denke, HTTP/2 führt einige neue Semantik (wie Server-Push), aber es ändert sich nicht von den bestehenden HTTP/1.x-Semantik, so ist es rückwärts kompatibel ist. Somit können web-Anwendungen können transparent aktualisiert auf HTTP/2.
    InformationsquelleAutor DenisM
  3. 0

    Den Hauptvorteil den ich sehe, ist der Server-Push für RESTful hypermedia APIs, die Verweise auf Ressourcen, die oft absolute domain-abhä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 Drücker verwendet werden können, um präventiv füllen Sie den browser-cache, wenn der server kennt den client wird wahrscheinlich wollen, um bestimmte GET-Anforderungen in der Zukunft.

    In dem obigen Beispiel, wenn der HTTP/2-Server-Push ist aktiviert und ordnungsgemäß konfiguriert, könnte es liefern /post/3, /post/13 und /post/06 zusammen mit /user/3.
    Aufeinander GETs zu einem dieser Beiträge führen würde zwischengespeicherten Antworten. Auch, der cache-digest Entwurf erlauben würde-client zum senden von Informationen über den Zustand Ihrer cache, Vermeidung unnötiger schiebt. Das ist viel praktischer für Hypermedia-getriebene APIs dann die eingebetteten Körper solche macht HAL.

    Mehr Informationen über die Gründe hier: Die Probleme mit der Einbettung in den REST von heute und wie könnte es gelöst werden mit HTTP/2.

    InformationsquelleAutor Jules Randolph
Schreibe einen Kommentar