streamalism.org

1. Bemutatkozás

Ebben az oktatóanyagban a Java 9 új inkubációját tárjuk fel HttpClient.

Egészen a közelmúltig a Java csak a HttpURLConnection API - amely alacsony szintű, és nem ismert funkciógazdagságárólésfelhasználóbarát.

Ezért gyakran használtak széles körben használt, harmadik féltől származó könyvtárakat - például az Apache HttpClient, a Jetty és a Spring's RestTemplate.

2. Kezdeti beállítás

A HTTP kliens modul inkubátor modulként van csomagolva a JDK 9-ben, és támogatja a HTTP / 2-t visszamenőleges kompatibilitással, még mindig elősegítve a HTTP / 1.1-et.

Használatához meg kell határoznunk modulunkat az a használatával module-info.java fájl, amely az alkalmazásunk futtatásához szükséges modult is jelzi:

modul com.baeldung.java9.httpclient {megköveteli jdk.incubator.httpclient; }

3. HTTP kliens API áttekintés

nem úgy mint HttpURLConnection, A HTTP kliens szinkron és aszinkron kérési mechanizmusokat biztosít.

Az API 3 alaposztályból áll:

• HttpRequest – képviseli a HttpClient
• HttpClient – a több kéréshez hasonló konfigurációs információk tárolójaként viselkedik
• HttpResponse – egy eredmény eredményét képviseli HttpRequest hívás

Mindegyiket részletesebben megvizsgáljuk a következő szakaszokban. Először koncentráljunk egy kérésre.

4. HttpRequest

HttpRequest, mint a név javasolja, egy olyan objektum, amely az elküldeni kívánt kérelmet képviseli. Új példányok hozhatók létre a HttpRequest.Builder.

Hívással megszerezhetjük HttpRequest.newBuilder (). Építész osztály kínál egy csomó módszert, amelyek segítségével konfigurálhatjuk kérésünket.

Kitérünk a legfontosabbakra.

4.1. Beállítás URI

Az első dolog, amit meg kell tennünk a kérelem létrehozásakor, meg kell adnunk az URL-t.

Ezt kétféleképpen tehetjük meg - a konstruktor használatával Építész val vel URI paraméterrel vagy hívási módszerrel uri (URI) a Építész példa:

HttpRequest.newBuilder (új URI ("// postman-echo.com/get")) HttpRequest.newBuilder () .uri (új URI ("// postman-echo.com/get"))

Utolsó dolog, amit konfigurálnunk kell egy alapkérés létrehozásához, egy HTTP módszer.

4.2. A HTTP-módszer megadása

Meghatározhatjuk a HTTP-metódust, amelyet a kérésünk használni fog, ha meghívjuk az egyik metódust Építész:

• KAP()
• POST (BodyProcessor body)
• PUT (BodyProcessor body)
• DELETE (BodyProcessor body)

Letakarjuk BodyProcessor később részletesen. Most csak alkossunk egy nagyon egyszerű GET kérési példa:

HttpRequest kérés = HttpRequest.newBuilder () .uri (új URI ("// postman-echo.com/get")) .GET () .build ();

Ennek a kérésnek megvan az összes paraméter, amelyet a HttpClient. Néha azonban további paramétereket kell felvennünk a kérésünkbe; íme néhány fontos:

• a HTTP protokoll verziója
• fejlécek
• időtúllépés

4.3. A HTTP protokoll verziójának beállítása

Az API teljes mértékben kihasználja a HTTP / 2 protokollt, és alapértelmezés szerint használja, de meghatározhatjuk, hogy a protokoll melyik verzióját akarjuk használni.

HttpRequest kérés = HttpRequest.newBuilder () .uri (új URI ("// postman-echo.com/get")) .version (HttpClient.Version.HTTP_2) .GET () .build ();

Fontos megemlíteni, hogy az ügyfél pl. HTTP / 1.1-re vált, ha a HTTP / 2 nem támogatott.

4.4. Fejlécek beállítása

Abban az esetben, ha további fejléceket szeretnénk felvenni a kérésünkbe, használhatjuk a megadott készítő módszereket.

Ezt kétféleképpen tehetjük meg:

• az összes fejlécet kulcsérték párként továbbítja a fejlécek () módszerrel vagy
• felhasználásával fejléc() módszer az egyetlen kulcsérték-fejléchez:

HttpRequest kérés = HttpRequest.newBuilder () .uri (új URI ("// postman-echo.com/get")) .fejek ("kulcs1", "érték1", "kulcs2", "érték2") .GET () .épít(); HttpRequest request2 = HttpRequest.newBuilder () .uri (új URI ("// postman-echo.com/get")) .header ("key1", "value1") .header ("key2", "value2"). GET () .build (); 

Az utolsó hasznos módszer, amellyel személyre szabhatjuk a kérésünket időkorlát ().

4.5. Időkorlát beállítása

Most határozzuk meg, hogy mennyi ideig várjunk a válaszra.

Ha a beállított idő lejár, a HttpTimeoutException dobni fogják; az alapértelmezett időtúllépés végtelenre van állítva.

Az időkorlát a Időtartam objektum - hívási módszerrel időtúllépés() az építő példányon:

HttpRequest kérés = HttpRequest.newBuilder () .uri (új URI ("// postman-echo.com/get")) .timeout (Duration.of (10, SECONDS)) .GET () .build ();

5. Kérelem szervének beállítása

Törzset hozzáadhatunk a kérelemhez a kérés-készítő módszerek használatával: POST (BodyProcessor body), PUT (BodyProcessor body) és DELETE (BodyProcessor body).

Az új API számos BodyProcessor dobozon kívüli megvalósítások, amelyek megkönnyítik a kérelem törzsének átadását:

• StringProcessor (kiolvassa a testet a Húr, a HttpRequest.BodyProcessor.fromString)
• InputStreamProcessor (kiolvassa a testet egy InputStream, a HttpRequest.BodyProcessor.fromInputStream)
• ByteArrayProcessor (törzset olvas le egy bájt tömbből, amelyet a HttpRequest.BodyProcessor.fromByteArray)
• FileProcessor (beolvassa a törzset az adott elérési útvonalon lévő fájlból, amelyet a HttpRequest.BodyProcessor.fromFile)

Ha nincs szükségünk testre, akkor egyszerűen átadhatunk egy HttpRequest.noBody ():

HttpRequest kérés = HttpRequest.newBuilder () .uri (új URI ("// postman-echo.com/post")) .POST (HttpRequest.noBody ()) .build ();

5.1. StringBodyProcessor

Kérelem testének beállítása bármelyikkel BodyProcessor a megvalósítás nagyon egyszerű és intuitív.

Például, ha át akarunk adni egy egyszerűt Húr mint test, használhatjuk StringBodyProcessor.

Mint már említettük, ez az objektum létrehozható gyári módszerrel fromString (); csak egy kell Húr az objektum mint argumentum és testet hoz létre belőle:

HttpRequest request = HttpRequest.newBuilder () .uri (new URI ("// postman-echo.com/post")) .headers ("Content-Type", "text / plain; charset = UTF-8") .POST (HttpRequest.BodyProcessor.fromString ("Minta kérés törzs")) .build (); 

5.2. InputStreamBodyProcessor

Ehhez a InputStream át kell adni a Támogató (hogy lustája legyen az alkotása), tehát kicsit más, mint a fent leírt StringBodyProcessor.

Ez azonban meglehetősen egyértelmű is:

byte [] sampleData = "Minta kérés törzs" .getBytes (); HttpRequest request = HttpRequest.newBuilder () .uri (new URI ("// postman-echo.com/post")) .headers ("Content-Type", "text / plain; charset = UTF-8") .POST (HttpRequest.BodyProcessor .fromInputStream (() -> new ByteArrayInputStream (sampleData))) .build (); 

Figyeljük meg, hogyan használtunk egy egyszerűt ByteArrayInputStream itt; az természetesen lehet bármilyen InputStream végrehajtás.

5.3. ByteArrayProcessor

Használhatjuk is ByteArrayProcessor és adja át a bájt tömböt paraméterként:

byte [] sampleData = "Minta kérés törzs" .getBytes (); HttpRequest request = HttpRequest.newBuilder () .uri (new URI ("// postman-echo.com/post")) .headers ("Content-Type", "text / plain; charset = UTF-8") .POST (HttpRequest.BodyProcessor.fromByteArray (sampleData)) .build ();

5.4. FileProcessor

A File használatához felhasználhatjuk a mellékelteket FileProcessor; gyári módszere paraméterként keresi a fájl elérési útját, és létrehoz egy törzset a tartalomból:

HttpRequest request = HttpRequest.newBuilder () .uri (new URI ("// postman-echo.com/post")) .headers ("Content-Type", "text / plain; charset = UTF-8") .POST (HttpRequest.BodyProcessor.fromFile (Paths.get ("src / test / resources / sample.txt")))) .build ();

Kitértünk az alkotás módjára HttpRequest és hogyan lehet további paramétereket beállítani benne.

Itt az ideje, hogy alaposabban megvizsgáljuk HttpClient osztály, amely felelős a kérések küldéséért és a válaszok fogadásáért.

6. HttpClient

Minden kérést a következővel küldünk: HttpClient amely a HttpClient.newBuilder () módszerrel vagy hívással HttpClient.newHttpClient ().

Nagyon sok hasznos és önmagát leíró módszert kínál, amelyeket felhasználhatunk kérésünk / válaszunk kezelésére.

Ezekről itt térjünk ki.

6.1. Proxy beállítása

Meghatározhatunk egy proxyt a kapcsolathoz. Csak hívjon meghatalmazott() módszer a Építész példa:

HttpResponse response = HttpClient .newBuilder () .proxy (ProxySelector.getDefault ()) .build () .send (request, HttpResponse.BodyHandler.asString ()); 

Példánkban az alapértelmezett rendszerproxyt használtuk.

6.2. Az átirányítási házirend beállítása

Néha az az oldal, amelyhez hozzáférni akarunk, másik címre költözött.

Ebben az esetben megkapjuk a 3xx HTTP állapotkódot, általában az új URI adataival együtt. HttpClient automatikusan átirányíthatja a kérést az új URI-ra, ha beállítjuk a megfelelő átirányítási házirendet.

Megtehetjük a followRedirects () módszer be Építész:

HttpResponse response = HttpClient.newBuilder () .followRedirects (HttpClient.Redirect.ALWAYS) .build () .send (request, HttpResponse.BodyHandler.asString ());

Az összes szabályzatot az enum határozza meg és írja le HttpClient.Redirect.

6.3. Beállítás Hitelesítő egy Kapcsolathoz

An Hitelesítő olyan objektum, amely hitelesítő adatokat (HTTP-hitelesítést) egyeztet a kapcsolat számára.

Különböző hitelesítési sémákat biztosít (például alap- vagy átfogó hitelesítést). A legtöbb esetben a hitelesítéshez felhasználónév és jelszó szükséges a szerverhez való csatlakozáshoz.

Tudjuk használni Jelszó hitelesítés osztály, amely csak az alábbi értékek birtokosa:

HttpResponse response = HttpClient.newBuilder () .authenticator (new Authenticator () {@Orride protected PasswordAuthentication getPasswordAuthentication () {return new PasswordAuthentication ("felhasználónév", "jelszó" .toCharArray ());}} (build). (kérés, HttpResponse.BodyHandler.asString ());

A fenti példában a felhasználónév és a jelszó értékeket átadtuk egyszerű szövegként; természetesen egy gyártási forgatókönyv esetén ennek másként kell lennie.

Ne feledje, hogy nem minden kérelemnek kell ugyanazt a felhasználónevet és jelszót használnia. A Hitelesítő osztály számos getXXX (például., getRequestingSite ()) módszereket, amelyekkel meg lehet tudni, hogy milyen értékeket kell megadni.

Most felfedezzük az új termékek egyik leghasznosabb tulajdonságát HttpClient - aszinkron hívások a szerverre.

6.4. Kérelmek küldése - Szinkronizálás és Async

Az Új HttpClient két lehetőséget kínál a kérelem kiszolgálóra történő elküldésére:

• Küld(…) - szinkron módon (blokkol, amíg meg nem érkezik a válasz)
• sendAsync (…) - aszinkron módon (nem várja meg a választ, nem blokkol)

Eddig a Küld(...) módszer természetesen megvárja a választ:

HttpResponse response = HttpClient.newBuilder () .build () .send (kérés, HttpResponse.BodyHandler.asString ()); 

Ez a hívás egy HttpResponse objektumot, és biztosak vagyunk benne, hogy az alkalmazásfolyamatunk következő utasítását csak akkor hajtjuk végre, amikor a válasz már itt van.

Ennek azonban sok hátránya van, különösen akkor, ha nagy mennyiségű adatot dolgozunk fel.

Tehát, most használhatjuk sendAsync (...) módszer - amely visszatér CompletableFeature – hogy egy kérést aszinkron módon dolgozzon fel:

CompletableFuture válasz = HttpClient.newBuilder () .build () .sendAsync (kérés, HttpResponse.BodyHandler.asString ());

Az új API több válasz kezelésére is képes, és továbbíthatja a kérés és válasz testeket:

Sorolja fel a célokat = Arrays.asList (új URI ("// postman-echo.com/get?foo1=bar1"), új URI ("// postman-echo.com/get?foo2=bar2")); HttpClient kliens = HttpClient.newHttpClient (); Lista futures = target.stream () .map (target -> client .sendAsync (HttpRequest.newBuilder (target) .GET (). build (), HttpResponse.BodyHandler.asString ()) .theApply (response -> response.body ( ))) .collect (Collectors.toList ());

6.5. Beállítás Végrehajtó aszinkron hívásokhoz

Meghatározhatunk egy Végrehajtó amely biztosítja az aszinkron hívások által használt szálakat.

Így korlátozhatjuk például a kérelmek feldolgozásához használt szálak számát:

ExecutorService végrehajtóService = Executors.newFixedThreadPool (2); CompletableFuture response1 = HttpClient.newBuilder () .executor (executorService) .build () .sendAsync (kérés, HttpResponse.BodyHandler.asString ()); CompletableFuture response2 = HttpClient.newBuilder () .executor (executorService) .build () .sendAsync (kérés, HttpResponse.BodyHandler.asString ());

Alapértelmezés szerint a HttpClient végrehajtót használja java.util.concurrent.Executors.newCachedThreadPool ().

6.6. Meghatározása a CookieManager

Az új API-val és a Builder alkalmazással egyszerű beállítani a CookieManager kapcsolatunkra. Használhatunk építő módszert cookieManager (CookieManager cookieManager) az ügyfélspecifikus meghatározásához CookieManager.

Például határozzuk meg CookieManager amely egyáltalán nem teszi lehetővé a sütik elfogadását:

HttpClient.newBuilder () .cookieManager (új CookieManager (null, CookiePolicy.ACCEPT_NONE)) .build (); 

Abban az esetben, ha a mi CookieManager lehetővé teszi a sütik tárolását, ellenőrzéssel hozzáférhetünk hozzájuk CookieManager tőlünk HttpClient:

httpClient.cookieManager (). get (). getCookieStore () 

Most koncentráljunk a Http API utolsó osztályára - a HttpResponse.

7. HttpResponse Tárgy

A HttpResponse osztály a szerver válaszát jelenti. Számos hasznos módszert kínál, de a két legfontosabb:

• statusCode () - visszaadja az állapotkódot (típus int) válaszra (HttpURLConnection osztály lehetséges értékeket tartalmaz)
• test() - egy testet ad vissza válaszként (a visszatérés típusa a választól függ BodyHandler paramétert továbbítottuk a Küld() módszer)

A válaszobjektumnak van más hasznos módszere, amelyre hasonlóan kitérünk uri (), fejlécek (), pótkocsik () és változat().

7.1. URI válaszobjektum

A módszer, a metódus uri () a válaszobjektumon a URI ahonnan megkaptuk a választ.

Néha lehet más, mint URI a request objektumban, mert átirányítás történhet:

assertThat (request.uri () .toString (), equalTo ("// stackoverflow.com")); assertThat (response.uri () .toString (), equalTo ("// stackoverflow.com/"));

7.2. Fejlécek a válaszból

A válaszból fejléceket szerezhetünk hívás módszerrel fejlécek () válaszobjektumon:

HttpResponse response = HttpClient.newHttpClient () .send (kérés, HttpResponse.BodyHandler.asString ()); HttpHeaders responseHeaders = válasz.fejlécek ();

Visszatér HttpHeaders objektum mint visszatérési típus. Ez egy új típus, amelyet a jdk.inkubátor.http csomag, amely a HTTP fejlécek csak olvasható nézetét képviseli.

Van néhány hasznos módszere, amely leegyszerűsíti a fejlécek értékének keresését.

7.3. Get Trailers from Response

A HTTP válasz további fejléceket tartalmazhat, amelyek a válasz tartalma után szerepelnek. Ezeket a fejléceket trailer fejléceknek nevezzük.

Megszerezhetjük őket hívási módszerrel pótkocsik () tovább HttpResponse:

HttpResponse response = HttpClient.newHttpClient () .send (kérés, HttpResponse.BodyHandler.asString ()); CompletableFuture trailer = response.trailers (); 

Vegye figyelembe, hogy pótkocsik () metódus visszatér CompletableFuture tárgy.

7.4. A válasz változata

A módszer, a metódus változat() meghatározza, hogy a HTTP protokoll melyik verzióját használták a szerverrel való beszélgetéshez.

Ne feledje, hogy még akkor is, ha meghatározzuk, hogy a HTTP / 2-t akarjuk használni, a szerver válaszolhat a HTTP / 1.1-n keresztül.

Az a verzió, amelyben a szerver válaszolt, meg van adva a válaszban:

HttpRequest kérés = HttpRequest.newBuilder () .uri (új URI ("// postman-echo.com/get")) .version (HttpClient.Version.HTTP_2) .GET () .build (); HttpResponse response = HttpClient.newHttpClient () .send (kérés, HttpResponse.BodyHandler.asString ()); assertThat (válasz.version (), egyenlőTo (HttpClient.Version.HTTP_1_1));

8. Java 11 Http kliens

A Java 11 legfontosabb változása a Java szabványosítása volt HTTP kliens API, amely megvalósítja a HTTP / 2 és a Web Socket alkalmazást. Célja az örökség pótlása HttpUrlConnection osztály, amely a Java legelső évei óta jelen van a JDK-ban.

A változtatást a JEP 321 részeként hajtották végre.

8.1. Jelentősebb változások a JEP 321 részeként

1. A Java 9 inkubált HTTP API-ja immár hivatalosan beépül a Java SE API-ba. Az új HTTP API-k itt találhatók: java.net.HTTP. *
2. A HTTP protokoll újabb verzióját úgy tervezték, hogy javítsa a kliens által küldött kérések és a szerver válaszainak fogadásának általános teljesítményét. Ezt számos változás bevezetésével érhetjük el, például adatfolyam multiplexelést, fejléctömörítést és push ígéreteket.
3. A Java 11-től kezdve az API most már teljesen aszinkron (az előző HTTP / 1.1 implementáció blokkolt). Az aszinkron hívásokat a CompletableFuture.A CompletableFuture a megvalósítás gondoskodik az egyes szakaszok alkalmazásáról, miután az előző befejeződött, így ez az egész folyamat aszinkron.
4. Az új HTTP kliens API szabványos módon biztosítja a HTTP hálózati műveletek végrehajtását, támogatva a modern webes szolgáltatásokat, például a HTTP / 2, harmadik féltől származó függőségek hozzáadása nélkül.
5. Az új API-k natív támogatást nyújtanak a HTTP 1.1 / 2 WebSocket számára. Az alapvető osztályok és az alapvető funkciókat biztosító interfész a következőket tartalmazza:

• A HttpClient osztály, java.net.http.HttpClient
• A HttpRequest osztály, java.net.http.HttpRequest
• A HttpResponse felület, java.net.http.HttpResponse
• A WebSocket felület, java.net.http.WebSocket

8.2. Problémák a Pre Java 11 HTTP klienssel

A létező HttpURLConnection Az API-nak és annak megvalósításának számos problémája volt:

• Az URLConnection API-t több olyan protokollal tervezték, amelyek már nem működnek (FTP, Gopher stb.).
• Az API korábbi a HTTP / 1.1-nél, és túl elvont.
• Csak blokkolási módban működik (azaz kérésenként / válaszonként egy szál).
• Nagyon nehéz fenntartani.

9. Változások a Http kliensben Java 11-vel

9.1. Statikus gyári osztályok bemutatása

Új statikus gyári osztályok BodyPublishers, BodySubscribers, és BodyHandlers bevezetik, amelyek magukban foglalják a BodyPublisher, BodySubscriber és BodyHandler.

Ezeket hasznos közös feladatok elvégzésére használják, például a válasz törzsének karakterláncként történő kezelésére vagy a törzs fájlba továbbítására.

Például a Pre Java 11-ben valami ilyesmit kellett tennünk:

HttpResponse response = client.send (kérés, HttpResponse.BodyHandler.asString ());

Amit most leegyszerűsíthetünk:

HttpResponse response = client.send (kérés, BodyHandlers.ofString ());

Ezenkívül a statikus módszerek nevét az egyértelműség érdekében egységesítették.

Például módszerek nevek, mint fromXxx akkor használjuk, amikor adapterként vagy hasonló névként használjuk őket of XXX amikor előre meghatározott kezelőket / előfizetőket hozunk létre.

9.2. Folyékony módszerek a közös testtípusokhoz

Kényelmes gyári módszereket vezettek be a létrehozott kiadók és kezelők számára a közös testtípusok kezelésére.

Például Az alábbiakban folyékony módszereket alkalmazunk a kiadók bájtokból, fájlokból és karakterláncokból történő létrehozására:

BodyPublishers.ofByteArray BodyPublishers.ofFile BodyPublishers.ofString

Hasonlóképpen, a kezelők létrehozásához ezekből a közös testtípusokból használhatjuk:

BodyHandlers.ofByteArray BodyHandlers.ofString BodyHandlers.ofFile

9.3. Egyéb API-változtatások

1. Ezzel az új API-val a következőket fogjuk használni BodyHandlers.discarding () és BodyHandlers.replacing (érték) ahelyett eldobás (objektumcsere):

HttpResponse response1 = HttpClient.newHttpClient () .send (kérés, BodyHandlers.discarding ());

HttpResponse response1 = HttpClient.newHttpClient () .send (kérés, BodyHandlers.replacing (érték));

2. Új módszer ofLines () ban ben BodyHandlers hozzá van adva, hogy a választest streamelését vonalak folyamaként kezelje.

3. fromLineSubscriber módszerrel egészül ki BodyHandlers osztály, amely adapterként használható a között BodySubscriber és szöveges Flow.Subscriber amely soronként elemzi a szöveget.

4. Hozzáadott egy új BodySubscriber.mapping ban ben BodySubscribers osztály, amely az egyik válasz testtípustól a másikig történő feltérképezésre használható az adott függvény test objektumra való alkalmazásával.

5. In HttpClient.Redirect, enum konstansok SAME_PROTOCOL és BIZTONSÁGOS politikát új felsorolás váltja fel NORMÁL.

10. A Push Promises kezelése a HTTP / 2-ben

Az új Http kliens támogatja a push ígéreteket PushPromiseHandler felület.

Lehetővé teszi a kiszolgáló számára, hogy „továbbítsa” a tartalmat az ügyfél további erőforrásaiba, miközben az elsődleges erőforrást kéri, több oda-vissza út megtakarítása és ennek eredményeként javítja az oldalmegjelenítés teljesítményét.

Valójában a HTTP / 2 multiplexelő szolgáltatása felejtheti el az erőforrások csomagolását. Minden egyes erőforráshoz a kiszolgáló külön kérést küld, amelyet push ígéretként ismerünk az ügyfélnek.

A kapott ígéreteket, ha vannak ilyenek, az adott kezeli PushPromiseHandler. A null értékű PushPromiseHnadler elutasít minden leküldéses ígéretet.

A HttpClient túlterhelt sendAsync módszer, amely lehetővé teszi számunkra az ilyen ígéretek kezelését, amint az az alábbi példában látható.

Először hozzunk létre egy PushPromiseHandler:

privát statikus PushPromiseHandler pushPromiseHandler () {return (HttpRequest initingRequest, HttpRequest pushPromiseRequest, Function> elfogadó) -> {elfogadó.alkalmazás (BodyHandlers.ofString ()) .thenAccept (resp -> {System.out.println ("Leküldött válasz:" + resp.uri () + ", fejlécek:" + ill. fejlécek) ());}); System.out.println ("Ígéretkérés:" + pushPromiseRequest.uri ()); System.out.println ("Ígéretkérés:" + pushPromiseRequest.headers ()); }; }

Ezután használjuk sendAsync módszer ennek a push ígéretnek a kezelésére:

httpClient.sendAsync (pageRequest, BodyHandlers.ofString (), pushPromiseHandler ()) .thenAccept (pageResponse -> {System.out.println ("Oldalválasz állapotkód:" + pageResponse.statusCode ()); System.out.println ( "Oldal válasz fejlécei:" + pageResponse.headers ()); String responseBody = pageResponse.body (); System.out.println (responseBody);}) .join (); 

11. Következtetés

Ebben a cikkben a Java 9-eket vizsgáltuk HttpClient API, amely sok rugalmasságot és hatékony funkciókat kínál. A Java 9 HttpClient API-jához használt teljes kód elérhető a GitHubon.

Felfedeztük a Java 11 HttpClient új változását is, amely erőteljesebb változásokkal egységesítette a Java 9-ben bevezetett inkubáló HttpClient szolgáltatást. A Java 11 Http klienshez használt kódrészletek a Githubon keresztül is elérhetők.

Megjegyzés: A példákban a REST végpontok mintáját használtuk //postman-echo.com.