Az API jelentése Application Programming Interface. Átjáróként szolgál az alkalmazások számára, hogy hozzáférjenek bizonyos erőforrásokhoz más alkalmazásokból.
Az API használatának előnye, hogy hozzáférést biztosít harmadik féltől származó alkalmazásokhoz, így azok nem férhetnek hozzá az alkalmazás teljes adatához. Csak azokhoz az adatokhoz férhetnek hozzá, amelyeket Ön az API-ján keresztül tesz közzé.
Az adatokhoz hozzáférni kívánó alkalmazást vagy felhasználót kliensnek, az adatokat kiszolgáló alkalmazást pedig szervernek nevezzük.
Az API-kat manapság széles körben használják minden szoftverarchitektúrában. Ha front-end, back-end, full-stack vagy hálózatmérnöki szerepkörre jelentkezik, akkor sok kérdést fognak feltenni az API-kkal kapcsolatban.
Ennek ellenére nézzük meg a REST API-kkal kapcsolatos leggyakrabban feltett interjúkérdéseket.
Tartalomjegyzék
Mi az a REST?
Válasz: A REST egy olyan építészeti terv, amely bizonyos korlátozásokat határoz meg az API-k működésére vonatkozóan. A REST elveit követő API-kat RESTful API-knak nevezzük. A REST a Representational State Transfer rövidítése.
Ez nem protokoll vagy szabvány; ehelyett ez egy olyan architektúra, amely különféle módokon használható API-k megvalósítására.
Nagy rugalmasságot és szabadságot biztosít a fejlesztők számára, ezért széles körben használják API-k fejlesztésére. Íme néhány REST architektúra alapelve:
- Az ügyfél és a kiszolgáló szétválasztása: A RESTful API-ban az ügyfél semmilyen más módon nem befolyásolhatja a kiszolgálót, mint az URI-n (Uniform Resource Identifier) keresztül történő adatkérést. Ugyanígy a szerver semmilyen módon nem módosíthatja a kliens tartalmát.
- Hontalanság: Ha két külön kérés érkezik, nem tudnak egymásról. Más szóval, a kérelmek hontalanok, és nem tartanak fenn állapotot. Ha egy kérés teljesül, egyszerűen megszűnik. Minden kérés elkülönítve van a többi kéréstől.
- Réteges architektúra: A kliens vagy a szerver nem tudja, hogy a kérés közvetlenül a forráshoz vagy egy közvetítő alkalmazáshoz érkezik-e. Csak a kérésre adott válasz érdekli őket.
- Gyorsítótárazás: Az adatok vagy válaszok gyorsítótárazhatók a kliens és a szerver oldalon is a teljesítmény és a méretezhetőség javítása érdekében. Ha gyakran érkeznek kérések egy adott erőforráshoz, akkor a kérésre adott válasz gyorsítótárazható, és szükség esetén felhasználható.
Mik a REST legfontosabb jellemzői?
Válasz: A REST fő jellemzői vagy jellemzői a következők:
- Rugalmasság: Áthelyezhet egyik szerverről a másikra, és ez nem változtat semmit, mert az API ugyanazt a választ küldi egy adott kérésre. Ezenkívül tetszőleges számú végpontot adhat hozzá a különböző típusú adatokhoz.
- Skálázhatóság: A gyorsítótárazás javítja a méretezhetőséget, mivel a válaszok mentésre kerülnek későbbi használatra. Csökkenti a szerver terhelését és a késleltetést is.
- Engedélyezés: Az engedélyezési fejléc segítségével megadhatja azokat a hitelesítő adatokat, amelyekkel a szerver engedélyezheti a kérést.
- Államtalanság: Ez a REST legfontosabb jellemzője, mert megakadályozza, hogy a kérések megtudják, mi történik más kérésekkel. A kéréseket elkülönítik, és amint teljesülnek, megszüntetik.
Mik az erőforrások a REST architektúrában?
Válasz: Az erőforrások olyan entitások, amelyeken különböző műveleteket hajtanak végre, például lekérést, frissítést vagy törlést. Ezek a REST architektúra alapvető építőkövei.
Például, ha egy online e-kereskedelmi üzletet vesz fontolóra, a termékek, a felhasználók és a metaadatok erőforrásnak számítanak, mivel kezelhetők. Az erőforrások átvihetők egy másik alkalmazásba az API-n keresztül.
Említse meg a REST API néhány előnyeit és hátrányait.
Válasz: A REST API-k előnyei a következők:
- Megvalósítása egyszerű.
- Az erőforrások könnyen kezelhetők.
- A kliens-szerver architektúra miatt méretezhető.
- Többféle adatátviteli adathordozót támogat, mint például az XML és a JSON.
Hátrányai a következők:
- Nem tarthat fenn állapotot a kérések között.
- Az erőforrás valódi származási forrása nem ismert a réteges architektúra miatt.
- Nem jó összetett lekérdezésekhez vagy kérésekhez.
Határozza meg a REST sablont.
Válasz: A REST-sablon egy segédprogram vagy egy kliens, amelyen keresztül elérheti a REST API-kat a Spring keretrendszerben. Alapvetően elrejti az általános kódot, amelyet esetleg meg kell írnia ahhoz, hogy erőforrást kérjen a REST API-tól.
Mi az a RESTful?
Válasz: A RESTful API-k vagy szolgáltatások olyan interfészek, amelyek megvalósítják a REST (Representational State Transfer) architektúra stílust, és protokollok, például HTTP használatával működnek.
Mik azok a RESTful webszolgáltatások?
Válasz: A RESTful webszolgáltatások úgy vannak kialakítva, hogy a legjobban működjenek az interneten. A reprezentatív állapotátvitel (REST) egy olyan architekturális stílus, amely olyan megszorításokat határoz meg, mint például az egységes felület, a réteges architektúra és az állapottalanság, ha webszolgáltatásra alkalmazzák, olyan kívánatos tulajdonságokat indukálnak, mint például a teljesítmény és a méretezhetőség, amelyek lehetővé teszik a szolgáltatások legjobb működését. a háló.
Hogyan tesztelheti a RESTful webszolgáltatásokat?
Válasz: A RESTful webszolgáltatás teszteléséhez használhat REST-ügyfelet, például Postman vagy Thunder Client-et, és lekérdezheti a tesztelni kívánt webszolgáltatást. Aztán, amikor választ kapsz, értsd meg a választ; ez a legfontosabb része.
Ha sok végponttal rendelkező összetett API-t szeretne tesztelni, előfordulhat, hogy le kell bontania a tesztelést, és végre kell hajtania az egységtesztet, az integrációs tesztelést, a teljesítménytesztet és a végpontok közötti tesztelést.
Említse meg a RESTful webszolgáltatások néhány szolgáltatását.
Válasz: A RESTful webszolgáltatások néhány fő jellemzője:
- Többféle médiatípus, például JSON és XML támogatása.
- Méretezhetőség
- Kliens és szerver elkülönítése
- Rugalmasság
Határozza meg a RESTful gyökér erőforrás osztályokat.
Válasz: A gyökérerőforrás-osztályok „sima régi Java objektumok” (POJO-k), amelyek vagy @Path megjegyzéssel vannak ellátva, vagy legalább egy metódusuk van @Path-szel vagy kérési metódus-jelölővel, például @GET, @POST, @PUT vagy @TÖRÖL.
Mi az URI?
Válasz: Az URI a Uniform Resource Identifier rövidítése. Ez egy API vagy szolgáltatás erőforrásainak megkeresésére vagy azonosítására használt karaktersorozat. Az erőforrás nevét vagy helyét használja az azonosításhoz, de nem támaszkodik egy adott módszerre vagy technikára.
Mi a hontalanság a REST-ben?
Válasz: A hontalanság egy olyan API-ra alkalmazott korlátozásra utal, amelyben bármely két kérelem nem tudhatja, hogy mi történik egymással. Más szóval, a kérések állapota nem marad fenn. Ha a kérés teljesül, a válasz megérkezése után egyszerűen megszűnik.
Mi az a JAX-RS?
Válasz: A JAX-RS egy Java API, amely lehetővé teszi a REST architektúrát használó alkalmazások fejlesztését Java nyelven. Ez az API megkönnyíti a REST alkalmazások fejlesztését Java nyelven.
Mik a legfontosabb megjegyzések a JAX-RS API-ban?
Válasz: A JAX-RS annotációit a fejlesztők a Java osztályok díszítésére használják, hogy meghatározzák az erőforrásokon végrehajtható erőforrásokat és módszereket. A JAX-RS API néhány kulcsfontosságú megjegyzése a következő:
- @GET: GET kérések küldésére használják HTTP-ben.
- @POST: POST kérések küldésére használják HTTP-ben.
- @Path: Egy Java osztály relatív elérési útjára utal.
- @QueryParam: Az URI vagy URL lekérdezési paramétereire utal.
Melyek a JAX-RS API néhány fő jellemzője?
Válasz: A JAX-RS jellemzői a következők:
- Kliens oldali gyorsítótár
- Szerver oldali gyorsítótár
- Lekérdezési karakterlánc testreszabása
- Futásidejű megjegyzések
Hogyan konfigurálhatók a JAX-RS alkalmazások?
Válasz: A JAX-RS alkalmazás legalább egy erőforrásosztályból áll, amely egy WAR fájlba van csomagolva. Az alap URI, amelyről az alkalmazás erőforrásai válaszolnak a kérésekre, kétféleképpen állítható be:
- Az @ApplicationPath annotáció használata a javax.ws.rs.core.Application alosztályában a WAR-ban
- A servlet-mapping címke használata a WAR web.xml telepítési leírójában
Mi az a JAX-WS és JAX-RS?
Válasz: A JAX-WS egy Jakarta XML Web Services API, amelyet API-k fejlesztésére használnak Simple Object Access Protocol (SOAP) – egy XML-alapú üzenetkezelési protokoll segítségével.
Másrészt a JAX-RS egy Java API, amelyet webszolgáltatások létrehozására használnak a REST architektúrát használva.
Mik azok a HTTP állapotkódok?
Válasz: Az állapotkódok nem más, mint a szerver által a kliens felé küldött válasz állapotának közlése. A szerver által küldött válaszfejlécekben jelen vannak.
A kliens az állapotkódok segítségével tudja megállapítani, hogy a kérés meghiúsult vagy teljesült-e, vagy a válaszban van-e valami hiba.
Íme néhány általános HTTP állapotkód: –
- 200 – az „OK” kulcsszót jelenti. Ez azt jelenti, hogy a kérést teljesítették, és a válasz rendben van.
- 404 – A „Not Found” rövidítése. Ez azt jelenti, hogy egy erőforrás nem található a kiszolgálón, vagy nem létezik végpont.
- 500 – „Belső szerverhiba” rövidítése. Ez általában akkor fordul elő, ha a kiszolgáló nem tudja generálni a megfelelő választ, vagy olyan hiba van, amelyet nem adtak ki kifejezetten.
- 503 – A „Szolgáltatás nem elérhető” rövidítése. Ez azt jelenti, hogy jelenleg a szerver nem tud kéréseket feldolgozni, valószínűleg azért, mert halott, vagy a kérés túlterhelése miatt nem működik. Ez akkor is előfordulhat, amikor a kiszolgáló karbantartás alatt áll.
Mik azok a HTTP-módszerek?
Válasz: A HTTP-metódusok bizonyos típusú műveletek végrehajtására szolgálnak az API egy adott erőforrásán. Ha például egy filmgyűjtemény API-ból szeretné lekérni a filmek listáját, akkor használhatja a HTTP által biztosított GET metódust. Ha frissíteni szeretné az adatokat, használhatja a HTTP által biztosított POST módszert.
A gyakran használt HTTP-módszerek a következők:
- GET: A GET-et használó kérések csak adatokat kérhetnek le.
- POST: Frissíti az erőforrást azáltal, hogy újonnan frissített erőforrást küld a kiszolgálónak.
- TÖRLÉS: Törli a megadott erőforrást.
- PATCH: Részben módosítja az erőforrást.
Hogyan működik a HTTP alapszintű hitelesítés?
Válasz: A hitelesítés egy olyan folyamat, amely az ügyfél hitelességének ellenőrzésére szolgál az adatbiztonság fenntartása érdekében. A HTTP-ben a hitelesítés egy engedélyezési fejlécen keresztül működik, amelyet az ügyfél küld el.
Az engedélyezési fejléc a kliens felhasználónevéből/azonosítójából és jelszavából áll, amelyet a szerver ellenőriz, és a hozzáférést megadja.
Egy fontos dolog, amit itt meg kell jegyezni, hogy HTTP-hitelesítés használatakor a csatornának, amelyen keresztül a hitelesítő adatok áthaladnak, titkosítottnak és biztonságosnak kell lennie.
A csatornát a HTTPS-be integrált SSL réteg használatával biztosíthatja. Tehát a hitelesítési adatok kezelésekor javasolt a HTTPS használata az egyszerű HTTP helyett.
Melyek a HTTP-kérés alapvető összetevői?
Válasz: A HTTP-kérés a következő összetevőkből áll:
- Kérelemsor: Bármely kérés első sora, és a HTTP metódusból, az elérési útból vagy végpontból és a HTTP verziószámból áll.
- Fejlécek: A HTTP-fejlécek a kérés metaadatainak biztosítására szolgálnak.
- Törzs (nem kötelező): Ez az összetevő csak néhány kérési metódusnál van jelen. Ez nem szükséges a GET kérésekhez, de szükséges a POST kérésekhez. Ez a kérés tényleges üzenete.
Melyek a HTTP-válasz alapvető összetevői?
Válasz: A HTTP-válasz a következő összetevőkből áll:
- Állapot: A szerver által küldött HTTP állapotkódra utal.
- Fejlécek: Csakúgy, mint a kéréseknek, a válaszoknak is megvannak a megfelelő fejlécei, amelyek hasznos információkat nyújtanak a válaszról.
- Üzenet: Ezek azok a tényleges adatok, amelyeket a szerver küld a kliensnek egy adott erőforrás lekéréséhez.
Mi a különbség a REST és az AJAX között?
Válasz: Az AJAX egy olyan kliens, amelyen keresztül elérheti a RESTful API-kat. Aszinkron kérések küldésére szolgál JavaScript használatával.
A REST vagy a Representational State Transfer egy olyan architektúra, amely megvalósítható RESTful API-k létrehozására. Röviden, HTTP kérések küldéséhez használhatja az AJAX-ot, amely ügyfélként szolgál, de ha RESTful API-kat szeretne megvalósítani, akkor REST architektúrát kell használnia.
Mi a különbség a SOAP és a REST között?
Válasz: A Representational State Transfer vagy a REST olyan architektúra, amely minimális megkötésekkel rendelkezik az API-k létrehozásához. A SOAP vagy Simple Object Access Protocol olyan protokoll, amely szigorú követelményeket támaszt az API megvalósításához.
A REST rugalmasabb és könnyebben használható, mint a SOAP. A SOAP-ban az XML-alapú üzenetkezelést használják, míg a REST-ben számos adatátviteli típust használhat, például JSON-t, XML-t stb. A SOAP-hoz képest a REST könnyebb és gyorsabb.
A SOAP webszolgáltatások beépített biztonsággal rendelkeznek, ami a SOAP használatának egyik előnye a REST-tel szemben, de a hozzáadott szolgáltatások bonyolulttá és nehézzé teszik a használatát.
Mi a különbség a PUT és a POST között?
Válasz: A POST egy HTTP kérési módszer, amely bizonyos adatokat küld a szervernek. Ha több POST-kérést ad le egy adott erőforráshoz, akkor az adatok mellékhatásai lehetnek. Ha például egy cikket szeretne hozzáadni egy gyűjteményhez, és több POST-kérést ad le, akkor több cikk is hozzáadódik a gyűjteményhez, ami redundáns cikkekhez vezet.
A PUT egy HTTP-kérési módszer, amely adatokat küld a szervernek egy adott erőforráshoz, de csak egyszer frissíti az adatokat. Ha több PUT-kérést küld egy adott erőforráshoz, akkor nem lép fel mellékhatás, és az adatok csak egyszer kerülnek hozzáadásra. A PUT-ban, ha az erőforrás nem létezik, akkor újat hoz létre, és ha létezik, akkor frissíti a meglévőt.
A PUT idempotens, míg a POST nem.
Mi az a hasznos teher?
Válasz: A REST API-ban található hasznos teher egyszerűen a klienstől a kiszolgálónak küldött kérés törzse. Ez az az adat, amelyet el szeretne küldeni a szervernek, és választ szeretne kapni.
Mekkora a postai úton elküldhető maximális rakomány mérete?
Válasz: Maga a HTTP protokoll nem állít be alapértelmezett korlátot. A korlát függhet a kliens vagy a szerver maximális korlátjától, attól függően, hogy melyik a minimum.
Melyek a bevált gyakorlatok az URI létrehozásakor?
Válasz: Néhány fontos szempont, amelyet szem előtt kell tartania az URI-k tervezése során:
- Kerülje a fájlkiterjesztések használatát
- Legyen következetes az összes URI-vel
- Ossza fel az URI-kat tartományokra és aldomainekre a különböző erőforráskészletekhez
- Az URI-kbe ágyazott mondatokban kötőjellel vagy aláhúzással kell elválasztani a szavakat
- Használja a perjelet az erőforrások hierarchiájának jelzésére
- Kódolja az URI-t megfelelő kódolással
- Próbálja meg az URI-t ember által olvashatóvá tenni
Mik azok az idempotens módszerek?
Válasz: Az Idempotens HTTP metódusok ugyanazt a hatást gyakorolják a szerverre, annak ellenére, hogy több azonos kérést küldenek. Például, ha egy adott erőforráshoz több azonos TÖRLÉS kérelmet küld, az erőforrás nem változik minden kérésnél; úgy frissül, mintha csak egy kérést küldtek volna el.
Néhány idempotens módszer:
- PUT
- TÖRÖL
- KAP
- FEJ
- LEHETŐSÉGEK
Mi az a Postás?
Válasz: A Postman egy API-fejlesztő eszköz API-k fejlesztésére, módosítására és tesztelésére. Számos funkciót biztosít az API-k gyors felépítéséhez és teszteléséhez, anélkül, hogy klienseket kellene beállítani.
Válasz: A Cache-Control fejléc utasításokból vagy direktívákból áll a gyorsítótárazás konfigurálására a böngészőkben és a szervereken. Megmondja a böngészőnek vagy a kiszolgálónak, hogy mit kell gyorsítótáraznia, és mennyi ideig kell tárolnia, mielőtt a hálózati kérés útján kérné.
A Cache-Control fejléc a következő direktívákat tartalmazza:-
- max-életkor
- nincs gyorsítótár
- magán
- nyilvános
- bolt nélküli
- változhatatlan
Határozza meg az üzenetkezelést a RESTful webszolgáltatásokban.
Válasz: Az üzenetküldés a RESTful webszolgáltatásokban azt jelenti, hogy az ügyfél HTTP-kérést küld a szervernek, amelyre a szerver HTTP-választ ad. Ezt a kommunikációt a kliens és a szerver között üzenetküldésnek nevezik.
Mi a különbség a Monolithic, a SOA és a Microservices architektúra között?
Válasz: A monolitikus építészetben mindent egy helyen kezelnek. A kliens oldal, a szerver és az adatbázis egy helyről kezelhető. Ezért nevezik monolitnak, mert a „monolit” szó egyetlen tömbre vagy kőre utal.
A SOA a Service-Oriented Architecture rövidítése. Ebben az architektúrában az alkalmazás különböző aspektusait különböző szolgáltatások kezelik, amelyek szintén szoftverek. Tehát ez több szolgáltatási szoftver modul kombinációja. Az integráció ennek az architektúrának a kulcseleme.
A Microservices architektúra hasonló a SOA-hoz, de a SOA-val ellentétben több önálló szoftverprogramja van, amelyek API-k segítségével kommunikálnak egymással. A monolitikus építészettel ellentétben itt minden autonóm és bizonyos mértékig független.
Hogyan működik a mikroszolgáltatási architektúra?
Válasz: A mikroszolgáltatási architektúrában az alkalmazások kisebb alegységekre vannak osztva, amelyek egymástól függetlenek és önállóan működnek, de egy jól meghatározott API-készleten keresztül kommunikálnak egymással.
A mikroszolgáltatási architektúra előnyei közé tartozik az agilitás, a rugalmasság, a méretezhetőség, a független technológiák, az újrafelhasználható szolgáltatások és az egyszerű üzembe helyezés.
Mi az a CRUD?
Válasz: A CRUD jelentése Create, Read, Update, Delete. Ezek azok a műveletek, amelyek egy adott erőforráson végrehajthatók. Az összes ilyen műveletet támogató API CRUD API néven ismert. Ezek a legalapvetőbb műveletek, amelyeket egy API hajthat végre egy erőforráson.
Mi az a gyorsítótárazás?
Válasz: A gyorsítótárazás egy válasz vagy kérés tárolási módszere az ügyfélen vagy a kiszolgálón, hogy később újra felhasználható legyen.
A válaszokat általában a kliens gyorsítótárában tárolják, mert ha az ügyfél rövid időintervallumon belül többször is benyújtja ugyanazt a kérést, akkor nincs értelme újra kérni a választ a hálózaton keresztül, és pazarolni a sávszélességet.
Mire jó a @RequestMapping?
Válasz: Ez egy megjegyzés a tavaszi keretrendszerben, amelyet arra használnak, hogy a webes kéréseket meghatározott kezelőosztályokra és/vagy kezelői metódusokra leképezzék.
Mit csinál a @PathVariable?
Válasz: A tavaszi keretrendszer @PathVariable annotációja a sablonváltozók értékének kinyerésére szolgál, és értéküket egy metódusváltozóhoz rendeli.
A HttpMessageConverter definiálása.
Válasz: Ha egy HTTP kérést (vagy annak egy részét) olyan típusra kell konvertálni, amely egy kezelő metódus argumentumaként szükséges, vagy ha a kezelő metódus által visszaadott értéket valamilyen módon konvertálni kell HTTP-válasz létrehozásához, a HTTP üzenetkonvertálókat használnak.
Válasz: Néhány eszköz, amely segíthet az API tesztelésében, a következők:
- Postás
- Nyugodj meg
- Pihenjen Sharp
- Katalon
- ReadyAPI
- Apigee
Végső szavak
Napjainkban az API-k rendkívül népszerűvé váltak az internet megjelenése miatt. A másik ok, amiért a REST API-k népszerűek, az, hogy könnyen fejleszthetők és könnyen használhatók.
Ha interjúra készül, fontolja meg a REST API-kkal kapcsolatos fenti kérdéseket, amelyeket az interjú során feltehet.
Ezután ellenőrizheti, hogyan lehet lekaparni egy webhelyet a etoppc.com Web Scraping API-jával.