Tartalomjegyzék[Elrejt][Előadás]
- 1. Mit értesz REST alatt?
- 2. Mit értesz REST API alatt?
- 3. Mi is pontosan az URI?
- 4. Mik a RESTful Web Services jellemzői?
- 5. Melyek a REST vezérelvei?
- 6. Említse meg a REST által támogatott HTTP metódusokat.
- 7. Ismertesse a konzisztens interfész által felállított korlátozásokat!
- 8. Mi is pontosan az a REST erőforrás?
- 9. Mit jelent számodra a JAX-RS?
- 10. Mi különbözteti meg az AJAX-ot és a REST-et egymástól?
- 11. Fel tudná sorolni néhány RESTful webszolgáltatás hátrányát?
- 12. Mi különbözteti meg egymástól a PUT és POST technikákat?
- 13. Hogyan teszteli a RESTful webszolgáltatásokat?
- 14. Írjon le egy REST API-t a való világban.
- 15. Hogyan működik a Microservice Architecture?
- 16. Mi is pontosan a gyorsítótárazás?
- 17. Ismertesse a hasznos terhet.
- 18. Megkülönböztetni a SOAP-t a REST-től?
- 19. Használható a szállítási réteg biztonsági protokollja (TLS) a REST-szel?
- 20. Idempotens módszerek: mik ezek? Hogyan vonatkozik ez a RESTful webszolgáltatások világára?
- 21. Mi a HTTP Basic Authentication funkciója?
- 22. Ön szerint a GraphQL a legjobb választás mikroszolgáltatási architektúra létrehozásához?
- 23. Mi a fő különbség a biztonságos és az idempotens HTTP metódusok között?
- 24. Mit jelent a JAX-RS API a RESTful Root Resource Classes által?
- 25. Mi is pontosan az a Postás, és miért használják?
- 26. Hogyan tartják biztonságban a REST API-kat?
- Következtetés
A REST evolúciója hihetetlenül hozzáférhetővé tette az API-kat, miközben felfedte teljes erejét és lehetőségeit. A REST API-k könnyen létrehozhatók és gyorsítótárazhatók az erőforrás-orientált architektúra miatt.
Ezenkívül az idők során a RESTful API-k más jelentős fejlesztések, például a felhőalapú számítástechnika és a mikroszolgáltatás-alapú tervezés előfutárai voltak.
Ezért nem meglepő, hogy a REST API fejlesztői ma keresettek, mivel versenyelőnyt biztosítanak a RESTful szolgáltatásokat alkalmazó vállalkozások számára. A REST API-k népszerű tervezési trendek.
Sok informatikai cég szeretne REST API tudást szerezni szoftverfejlesztők és kérdezz rá a technikai interjúkon.
Íme néhány a legjellemzőbb REST API interjúkérdések, amelyek segítenek felkészülni a különböző cégek interjúira, ha a REST API fejlesztési területen szeretne dolgozni.
1. Mit értesz REST alatt?
A REST egy architekturális paradigma a HTTP-n (Hypertext Transfer Protocol) alapuló webalapú alkalmazások tervezésére.
A REST meghatároz bizonyos szabványokat, amelyeknek a webszolgáltatásoknak meg kell felelniük ahhoz, hogy REST-teljesnek minősüljenek. Ezek az ajánlások garantálják a kérések és erőforrások gyors és hatékony továbbítását az ügyfél és a szerver között szabványos HTTP-protokollok használatával.
2. Mit értesz REST API alatt?
Az alkalmazás-programozási interfészként ismert szoftver-szoftver kapcsolat lehetővé teszi az egyébként független programok közötti kommunikációt és adatmegosztást. Például egy hírwebhely használhatja a Twitter API-t, hogy automatikusan felfedezze a releváns tweeteket, és integrálja azokat a hírekbe.
A REST-elveket betartó API-t REST API-nak, néha RESTful API-nak is nevezik. A REST API-ban minden adatot erőforrásként kezel, és külön szabványos erőforrás-azonosítót (URI) kap.
Például a Twitter API minden tweetet visszakereshető erőforrássá tesz, amely elérhető az ügyfelek számára. A Twitter API-t a felhasználók tweetek közzétételére és egyéb webhelyfeladatok elvégzésére használhatják.
3. Mi is pontosan az URI?
A számítógép hálózat az erőforrásra URI vagy egységes erőforrás-azonosító használatával hivatkozhatunk. Eszközként szolgál az egyik erőforrás elválasztására a másiktól. Lehetséges, hogy a források online vannak, vagy nem.
Szabványos felépítésüknek köszönhetően az URI-k egyszerűvé teszik a csatlakozást akár különféle típusú erőforrásokhoz is. Az erőforrás helye vagy neve egy karakterlánccal együtt szerepel az URI-kban.
Az URI útvonalból, sémából, lekérdezésből és egyéb elemekből áll, de nem tartalmazza a protokollt.
Protokoll használatával az URL-ek (Uniform Resource Locators) az interneten vagy azon keresztül elérhető források megkeresésére szolgálnak.
4. Mik a RESTful Web Services jellemzői?
- A kliens-szerver paradigma a szolgáltatás alapja.
- A szolgáltatás URI-n keresztül férhet hozzá az erőforrásokhoz.
- A szolgáltatás a HTTP protokollt használja adatok/erőforrások beszerzésére, lekérdezések futtatására és egyéb feladatok elvégzésére.
- Az üzenetküldés a kliens és a szerver közötti kommunikációra használt módszer neve.
- Ezek a szolgáltatások a REST architektúra mintát is megvalósíthatják a SOAP szolgáltatások segítségével.
- Az azonos típusú ismétlődő kérések kiszolgálóhívásainak csökkentése érdekében ezek a szolgáltatások a gyorsítótárazás ötletét is alkalmazzák.
5. Melyek a REST vezérelvei?
A REST API-knak öt kritériumnak kell megfelelniük:
Kliens-szerver szétválasztás: Csak kérések és válaszok sorozata használható a kliens és a szerver közötti kommunikációhoz. Csak a kliensek és a szerverek tudnak kéréseket és válaszokat küldeni. Ez az egyszerű ötlet lehetővé teszi mindkét fél számára, hogy egymástól függetlenül működjenek.
Egységes interfész: Minden kliens-szerver kapcsolathoz egységes protokollnak kell lennie. Ez a REST protokoll a HTTP. Mivel minden alkalmazás ugyanazon a nyelven kér és küld adatokat, a konzisztens felület egyszerűbbé teszi az integrációt.
Állapot nélküli: A szerver nem menti el a korábbi kérések vagy válaszok rekordját az állapot nélküli kommunikáció során. Minden kérés és válasz megadja a csere befejezéséhez szükséges összes adatot. Az állapot nélküli kommunikáció növeli a sebességet, memóriát takarít meg, és csökkenti a szerver stresszét. Ezenkívül elkerüli annak lehetőségét, hogy egy kérés meghiúsuljon hiányos adatok miatt.
Réteges rendszer: Azokat a szervereket, amelyek az ügyfél és az API-kiszolgáló között helyezkednek el, rétegeknek nevezzük. Ezek az extra szerverek számos szolgáltatást hajtanak végre, mint például a spam észlelése és a sebesség optimalizálása. A REST rétegei modulárisak, ami azt jelenti, hogy hozzáadhatók és törölhetők anélkül, hogy befolyásolnák a kliens és az API-kiszolgáló közötti kommunikációt.
Gyorsítótárazható: Az ügyfelek gyorsítótárazhatnak bármilyen erőforrást a sebesség növelése érdekében, ha a szerver válaszai jelzik, hogy az erőforrás gyorsítótárazható-e vagy sem.
Igény szerinti kódolás: Válaszul egy API futtatható számítógépes kódot küldhet az ügyfeleknek. Az ügyfélalkalmazás ezután futtathatja a kódot a saját hátterén.
6. Említse meg a REST által támogatott HTTP metódusokat.
A REST által támogatott HTTP metódusok a következők:
- GET: Ez a metódus erőforrást kér a megadott URL-címen. A kérelem törzsét nem szabad megadni, mert a rendszer figyelmen kívül hagyja. Lehetséges lehet helyileg vagy a szerveren gyorsítótárazni.
- POST: Ez a módszer adatokat küld egy szolgáltatásnak feldolgozásra, és a szolgáltatásnak általában új vagy módosított erőforrást kell visszaadnia.
- PUT: Az erőforrás frissítése a kérés URL-címén történik.
- TÖRLÉS: Az erőforrás törlésre kerül a kérés URL-címén.
- Opciók: A támogatott módszereket azonosítja.
- HEAD: A kérés URL-jének metaadatait a rendszer visszaküldi.
7. Ismertesse a konzisztens interfész által felállított korlátozásokat!
A kliens és a szerver elválasztásához konzisztens interfész szükséges.
A következetes interfész eléréséhez a következő négy megkötés szükséges:
- Erőforrás azonosítás: Az ügyfélkérelmeknek szabványos erőforrás-azonosítókat kell használniuk az erőforrások azonosításához (URI).
- Erőforrás-manipuláció az alábbi reprezentációk használatával: Az ügyfelek minden szükséges információval rendelkeznek ahhoz, hogy módosítsák az erőforrás állapotát, amikor erőforrás-ábrázolást kapnak a kiszolgálótól.
- Önleíró üzenetek: Az üzenetek tartalmazzák az összes metaadatot és egyéb információt, amely ahhoz szükséges, hogy a címzett megértse őket.
- Hipermédia, mint az alkalmazás állapotmotorja: A kliens-szerver kommunikáció csatornája a hipermédia, például a HTML, és az ügyfeleknek nincs szükségük API-specifikus dokumentációra a szerver válaszainak megértéséhez.
8. Mi is pontosan az a REST erőforrás?
Az erőforrások a REST-architektúra RESTful webszolgáltatásának alapvető összetevői. Tartalmaznak minden lényeges információt, amelyhez egy API-kliensnek hozzá kell férnie.
Bármilyen típusú erőforrás, például HTML oldal, kép, videó vagy bármi más, ami egy API tevékenységhez szükséges, elérhető a szerveren keresztül egy kliens-szerver rendszerben.
Az erőforrásokat egységes erőforrás-azonosító azonosítja. A szöveg, a JSON vagy az XML az erőforrások elfogadható reprezentációja. Ennek ellenére az ábrázolás formátumára nincs korlátozás.
9. Mit jelent számodra a JAX-RS?
Egyszerűbb a RESTful webszolgáltatások létrehozása Java nyelven a Java API for RESTful web Services, gyakran JAX-RS néven ismert API-nak köszönhetően. A fejlesztők leírhatják az erőforrásokat és a rajtuk végrehajtható műveleteket a biztosított megjegyzések segítségével.
10. Mi különbözteti meg az AJAX-ot és a REST-et egymástól?
ajax:
- Az Ajax olyan technológiák csoportja, amelyek lehetővé teszik a dinamikus frissítést felhasználói felület elemeket anélkül, hogy újra kellene töltenie az oldalt.
- Az Ajax eltávolítja az aszinkron kommunikációt a kliens és a szerver között.
PIHENÉS:
- A REST kommunikációt igényel a szerver és a kliens között.
- Az erőforrások felhasználása fontos a REST által használt URL-struktúra és kérés/válasz minta szempontjából.
11. Fel tudná sorolni néhány RESTful webszolgáltatás hátrányát?
Az ülések nem tarthatók fenn, mivel a szolgálatok a hontalanság fogalmához ragaszkodnak. (Az ügyfél felelős azért, hogy a munkamenet azonosítóját átadja a szimuláció során.)
A biztonsági megszorítások nem alapvetőek a REST számára. Az ezt használó protokollok öröklik a biztonsági óvintézkedéseket. Ezért fontos, hogy körültekintően járjon el a biztonsági intézkedések, például az SSL/TLS-alapú hitelesítések integrálása során.
12. Mi különbözteti meg egymástól a PUT és POST technikákat?
PUT:
- Nincs gyorsítótár a PUT válaszokhoz.
- Idempotens (azaz több kérés ugyanazt az eredményt adja)
- a kérés hasznos tartalma frissíti vagy lecseréli a célerőforrást.
POST:
- idempotens not (azaz több kérés ugyanannak az erőforrásnak a többszörösét eredményezi)
- A webszerver a kérés hasznos terhét a tervezett erőforrás alapján dolgozza fel.
- Ha a megfelelő cache-control fejléc szerepel, a POST válaszok gyorsítótárazhatók.
13. Hogyan teszteli a RESTful webszolgáltatásokat?
A RESTful webszolgáltatás tesztelését számos eszköz segítheti, köztük a Swagger és a Postman. A kérésparaméterek, például a lekérdezési paraméterek, fejlécek és válaszfejlécek ellenőrzését az utóbbi rengeteg szolgáltatása teszi lehetővé.
A Postman segítségével kéréseket lehet küldeni a végpontokhoz és megjeleníteni az eredményeket. És ezekből a válaszokból XML és JSON hozható létre.
A Postman és a Swagger rendkívül összehasonlítható funkciókat kínál. Másrészt a Swagger olyan lehetőségeket is kínál, mint a végpontok dokumentációja.
14. Írjon le egy REST API-t a való világban.
- Az utazási és jegyértékesítő webhelyek kihasználhatják a légitársaságok által API-kon keresztül elérhető repülési időzítéseket és árakat.
- Annak érdekében, hogy a térképészeti és navigációs alkalmazások (például a Google Térkép) használhassák őket, a tömegközlekedési ügynökségek gyakran nyilvánosan elérhetővé teszik adataikat valós időben API-kon keresztül.
- Az időjárási alkalmazások nyílt API-kat használnak, amelyek időjárási adatokat cserélnek az időjárási információk megjelenítéséhez.
- A fejlesztők hozzáférhetnek a Google Térkép térképi adataihoz számos hosztolt API-n keresztül. Ezeket az API-kat a fejlesztők arra használják, hogy dinamikus térképeket ágyazzanak be alkalmazásaikba és webhelyeikbe.
15. Hogyan működik a Microservice Architecture?
- A kéréseket különböző ügyfelek küldik el különböző eszközök segítségével.
- Az ügyfelek személyazonosságának megerősítése után az identitásszolgáltatók biztonsági tokeneket biztosítanak.
- Az ügyfélkérelmeket az API Gateway kezeli.
- A rendszer összes anyaga statikus tartalomként megmarad.
- A felügyeleti eszköz ellenőrzi a szolgáltatások egyensúlyát a csomópontokon és az esetleges hibákat.
- A mikroszolgáltatások közötti kommunikációs út felfedezését a szolgáltatásfelderítés segíti.
- Az adatközpontok és a proxyszerverek szétszórt hálózati rendszereket alkotnak, amelyeket tartalomszolgáltató hálózatoknak neveznek.
- A távoli szolgáltatások távolról biztosítják az információk elérését.
16. Mi is pontosan a gyorsítótárazás?
Gyorsítótárazásnak nevezik azt a gyakorlatot, hogy a szerver válaszának másolatát ideiglenesen megőrzik valahol (például a számítógép memóriájában), hogy azt később gyorsabban elérjék.
A gyorsítótárazás növeli a szerver sebességét REST API-k használatakor azáltal, hogy csökkenti a kiszolgálónak a kérés teljesítéséhez szükséges munkáját. Az API-t használó alkalmazások gyorsabban futnak a gyorsítótárazásnak köszönhetően, mert nem kell minden alkalommal új kérelmet benyújtaniuk, amikor erőforrásra van szükségük.
A HTTP-válasz fejlécének Cache-Control mezője információkat tartalmaz arról, hogy az ügyfél mennyi ideig tárolhat gyorsítótárban egy erőforrást, mielőtt ismételten hozzá kell férnie.
17. Ismertesse a hasznos terhet.
A REST-ben lévő hasznos terhelés a HTTP-válasz törzsében található információra vonatkozik. Az ügyfél a GET technikát használta a kérdéses adatok lekérésére.
A tweet szövegét és a tweet webhelyen való elhelyezéséhez szükséges fájlokat tartalmazó dokumentum bekerül a hasznos terhelésbe, például ha egy adott tweetet kér a Twitter API-tól. Ezenkívül a POST metódus használatával a hasznos terhelés bekerülhet a HTTP-kérésbe.
18. Megkülönböztetni SZAPPAN Vs REST?
- A SOAP-tól eltérően, amely csak XML-t tud kezelni, a REST az erőforrás-formátumok szélesebb skáláját teszi lehetővé, beleértve az XML-t, szöveget, HTML-t, képeket, videókat és egyebeket.
- Amikor a biztonság kulcsfontosságú az online alkalmazásokhoz, a SOAP hasznos. A REST nem használható, ha a tranzakciókat biztonságosan kell végrehajtani, mivel nem különösebben biztonságos.
- Mivel a SOAP csak egy protokoll, a REST használhatja webszolgáltatásaiban, de fordítva nem.
- Míg a REST csak egy architekturális minta, amelyet webszolgáltatások fejlesztésére használnak, és betart bizonyos korlátokat, mint például a kliens-szerver beállítás, az állapottalanság, a gyorsítótárazás, a réteges rendszerek és a konzisztens interfész, a SOAP egy olyan protokoll, amely meghatározott szabványokon működik, amelyeket szigorúan be kell tartani. nak nek.
- Míg a REST univerzális erőforrás-azonosítókat (URI) használ, a SOAP szolgáltatási interfészek segítségével biztosítja képességeit az ügyfélalkalmazások számára. A REST-nek kisebb sávszélesség-igénye van, mint a SOAP-nak, mivel a SOAP-üzenetek információigényesebbek.
19. Használható a szállítási réteg biztonsági protokollja (TLS) a REST-szel?
Sőt, megtehetjük. A REST kliens és a szerver kommunikációja TLS-en keresztül titkosított, és a protokoll lehetőséget ad az ügyfeleknek a szerverek hitelesítésére is.
Tekintettel arra, hogy ez a Secure Socket Layer helyettesítője, biztonságos kommunikációra (SSL) használják. A RESTful webszolgáltatások megvalósítása sikeres a HTTPS-sel, mert hatékonyan együttműködik mind a TLS-lel, mind az SSL-lel.
A REST örökli az általa megvalósított protokoll jellemzőit, amit itt érdemes megjegyezni. Ennek eredményeként a biztonsági védelem a REST által használt protokolltól függ.
20. Idempotens módszerek: mik ezek? Hogyan vonatkozik ez a RESTful webszolgáltatások világára?
Ha az URI azonos, akkor a kérés egyes HTTP-metódusai ugyanolyan hatással vannak a kiszolgálóra, akár egyszer, akár többször kézbesítik őket. Idempotens technikáknak nevezzük ezeket.
Például, függetlenül attól, hogy hányszor fut le egy GET metódust használó URI, a szerver mindig ugyanazt az eredményt fogja tapasztalni. Idempotens módszerek közé tartozik a GET, PUT és PATCH, hogy csak néhányat említsünk.
Idempotens HTTP metódusok a RESTful által használtak webes alkalmazások. Ezek szükségesek a RESTful webszolgáltatások tevékenységének következetességének garantálásához.
A REST API-kat használó ügyfelek olyan kódhibákat követhetnek el, amelyek arra kényszerítik a REST API-t, hogy véletlenül ismétlődő kéréseket tegyen. Ezek a hívások az erőforrásokkal való visszaélés lehetőségét hordozzák magukban.
21. Mi a HTTP Basic Authentication funkciója?
Amikor az alapszintű hitelesítést API-k részeként használja, a felhasználónak meg kell adnia a felhasználónevet és a jelszót, amelyeket a böngésző „felhasználónév: jelszó” formában és base64 kódolással összefűz.
A böngészőtől érkező minden HTTP-kérelemnél a kódolt érték az „Authorization” fejléc értékeként jelenik meg. Mivel a hitelesítő adatok csak kódolva vannak, ajánlott ezt az űrlapot használni HTTPS-kérések küldésekor, mivel azok nem biztonságosak, és bárki elfoghatja őket, ha nem használják a biztonsági protokollokat.
22. Ön szerint a GraphQL a legjobb választás mikroszolgáltatási architektúra létrehozásához?
A mikroszolgáltatások és a GraphQL tökéletesen illeszkednek egymáshoz, mert a GraphQL titokban tartja a mikroszolgáltatási architektúrát az ügyfelek előtt.
Az előtérből azt szeretné, hogy minden adata egyetlen API-ból származzon, míg a háttérből mikroszolgáltatásokra szeretné felosztani. Az általam ismert legjobb technika mindkettő eléréséhez a GraphQL használata.
Lehetővé teszi a háttérrendszer felosztását mikroszolgáltatásokra, miközben minden alkalmazásnak egyetlen API-t biztosít, és lehetővé teszi a különböző szolgáltatások adatainak összekapcsolását.
23. Mi a fő különbség a biztonságos és az idempotens HTTP metódusok között?
Az identitástudó metódusok ugyanazt az eredményt produkálják, ha egyszer vagy többször ugyanazon kérésen keresztül meghívják őket. A PUT módszer idempotens.
Minden biztonságos módszer idempotens, de nem minden idempotens módszer biztonságos, mivel a biztonságos módszerek nem változtatják meg az erőforrásokat. Például a GET biztonságos, mivel csak adatokat kér le, és nem módosítja az erőforrást.
Ezenkívül idempotens, ami azt jelenti, hogy mindig ugyanazt a választ adja vissza, amikor meghívják.
24. Mit jelent a JAX-RS API a RESTful Root Resource Classes által?
A Java Enterprise Edition olyan osztályokat és felületeket biztosít, amelyek megfelelnek a JAX-RS API követelményeinek. A JAX-RS segítségével a Java webszolgáltatások REST építészeti stílusban való létrehozása egyszerűbbé válik.
A JAX-RS API-ban a gyökér erőforrás osztályok csak „sima régi java objektumok” vagy POJO. A szükséges webes erőforrások megvalósítása érdekében JAX-RS annotációkat alkalmaznak.
Vagy rendelkeznek @path annotációkkal, vagy legalább egy metódusuknak van @path annotációja. Java osztályokként foglalhatók össze az API-végpontok kezelésére szolgáló metódusokkal.
25. Mi is pontosan az a Postás, és miért használják?
A Postman nevű API-fejlesztő eszközt API-k létrehozására, tesztelésére és módosítására használják. Ezt az eszközt a fejlesztők bármilyen funkcióhoz használhatják, amelyre egy API-hoz szükségük van. Leegyszerűsíti és megkönnyíti a fejlesztők munkáját.
A Postman megkönnyíti a különféle HTTP-lekérdezések elkészítését, beleértve a GET, POST, PUT és PATCH lekérdezéseket, környezetek mentését későbbi használatra, és API-k kódokká alakítását számos különböző nyelven.
Az API-ciklus minden szakasza leegyszerűsödik a Postman segítségével, és az együttműködés ésszerűsödik a gyorsabb API-fejlesztés érdekében.
Ezenkívül lehetővé teszi a fejlesztők számára a dokumentáció, a specifikációk, a tesztesetek, a folyamatok és az API-katalógusok kezelését.
26. Hogyan tartják biztonságban a REST API-kat?
Mivel a REST API-k nem alkalmaznak olyan szigorú biztonsági óvintézkedéseket, mint a SOAP API-k, érzékeny adatok nem küldhetők vagy kérhetők le velük.
A megbízható REST API-k azonban továbbra is integrálják a biztonsági ellenőrzéseket a biztonságos és megbízható adatátvitel érdekében.
- Hitelesítés és engedélyezés: Minden API-nak küldött kérésnek át kell mennie ezen a két ellenőrzésen. Az ügyfél személyazonosságának hitelesítéssel történő ellenőrzése és annak ellenőrzése, hogy jogosultságuk van-e a kért erőforrásokhoz való hozzáférésre, két különböző folyamat.
- Érvényesítés: Mielőtt az API hozzáférést adna erőforrásaihoz, a kéréseket a hitelesítés és engedélyezés után is ellenőrizni kell, hogy nem tartalmaznak-e káros kódot. A szerver így nyitott lenne egy injekciós támadásra.
- Érvényesítés: Mielőtt az API hozzáférést adna erőforrásaihoz, a kéréseket a hitelesítés és engedélyezés után is ellenőrizni kell, hogy nem tartalmaznak-e káros kódot. A szerver így nyitott lenne egy injekciós támadásra.
- Titkosítás: A TLS/SSL titkosítás védi az ügyfél és a szerver közötti kapcsolatot, és megakadályozza, hogy a hackerek elkapják a kéréseket és válaszokat.
- Az olyan sebességkorlátozó technikák, mint a korlátozások és a szabályozás, megvédik a szervereket az olyan nyers erejű támadásoktól, mint a DDoS, amelyek célja azok leromlása vagy összeomlása.
- Nincsenek bizalmas információk az URI-kban: Az erőforrások URI-i nem tartalmazhatnak védett adatokat (például felhasználónevet, jelszót vagy hitelesítési tokent).
Következtetés
Gratulálunk! Számos alapvető és összetett REST API interjúkérdés és a hozzájuk tartozó megoldások most kéznél vannak.
Most, hogy van egy jó elképzelése arról, hogyan válaszoljon néhány tipikus REST API interjúkérdésre, folytathatja az interjúk megválaszolását. A következő lépés az Ön céljaitól függ.
Látogat Interjú sorozat Hashdorkkal, hogy felkészüljenek az interjúkra.
Hagy egy Válaszol