Përmbajtje[Fshih][Shfaqje]
- 1. Çfarë kuptoni me REST?
- 2. Çfarë kuptoni me REST API?
- 3. Çfarë është saktësisht URI?
- 4. Cilat janë karakteristikat e RESTful Web Services?
- 5. Cilat janë parimet drejtuese të REST?
- 6. Përmendni metodat HTTP që mbështet REST.
- 7. Përshkruani kufizimet e vendosura nga një ndërfaqe konsistente.
- 8. Çfarë është saktësisht një Burim REST?
- 9. Çfarë do të thotë JAX-RS për ju?
- 10. Çfarë i dallon AJAX-in dhe REST-in nga njëri-tjetri?
- 11. A mund të listoni disa të meta të shërbimeve të uebit RESTful?
- 12. Çfarë i dallon teknikat PUT dhe POST nga njëra-tjetra?
- 13. Si i testoni shërbimet e internetit RESTful?
- 14. Përshkruani një API REST në botën reale.
- 15. Si funksionon Arkitektura Microservice?
- 16. Çfarë saktësisht është caching?
- 17. Përshkruani ngarkesën.
- 18. Dalloni sapunin nga PUSHIMI?
- 19. A mund të përdoret protokolli i sigurisë së shtresës së transportit (TLS) me REST?
- 20. Metodat idempotente: cilat janë ato? Si zbatohet në botën e shërbimeve të internetit RESTful?
- 21. Cili është funksionaliteti i Autentifikimit Bazë HTTP?
- 22. A mendoni se GraphQL është zgjidhja më e mirë për krijimin e arkitekturës së mikroservisit?
- 23. Cilat janë dallimet kryesore ndërmjet metodave HTTP të sigurta dhe idempotente?
- 24. Çfarë nënkupton JAX-RS API nga RESTful Root Resource Classes?
- 25. Çfarë është saktësisht Postman dhe pse përdoret?
- 26. Si mbahen të sigurta API-të REST?
- Përfundim
Evolucioni i REST i ka bërë API-të tepër të aksesueshme, duke zbuluar gjithashtu fuqinë dhe potencialin e tyre të plotë. API-të REST janë të lehta për t'u krijuar dhe për t'u memorizuar për shkak të arkitekturës së tyre të orientuar nga burimet.
Për më tepër, gjatë gjithë kohës, API-të RESTful ishin pararendësit e zhvillimeve të tjera të rëndësishme si kompjuteri në renë kompjuterike dhe dizajni i bazuar në mikroshërbime.
Prandaj, nuk duhet të jetë befasi që zhvilluesit e REST API janë në kërkesë sot duke pasur parasysh se si u ofrojnë bizneseve që përdorin shërbimet RESTful një avantazh konkurrues. API-të REST janë një prirje e njohur e dizajnit.
Shumë firma IT duan njohuri nga REST API zhvilluesit e softuerit dhe pyesni për këtë në intervista teknike.
Këtu janë disa nga pyetjet më tipike të intervistës REST API që do t'ju ndihmojnë të jeni gati për intervista në firma të ndryshme nëse dëshironi të punoni në fushën e zhvillimit të REST API.
1. Çfarë kuptoni me REST?
REST është një paradigmë arkitekturore për dizajnimin e aplikacioneve të bazuara në ueb që bazohen në Protokollin e Transferimit të Hypertext (HTTP).
REST përcakton disa standarde që shërbimet e uebit duhet të plotësojnë për t'u konsideruar RESTful. Këto rekomandime garantojnë që kërkesat dhe burimet të transmetohen shpejt dhe në mënyrë efektive midis klientit dhe serverit duke përdorur protokolle të standardizuara HTTP.
2. Çfarë kuptoni me REST API?
Një lidhje softuerësh me softuerin e njohur si një ndërfaqe programimi aplikacioni mundëson komunikimin dhe ndarjen e të dhënave ndërmjet programeve ndryshe të pavarura. Për shembull, një faqe interneti lajmesh mund të përdorë API-në Twitter për të zbuluar automatikisht cicërima përkatëse dhe për t'i integruar ato në lajme.
Një API që i përmbahet parimeve REST njihet si një API REST, ndonjëherë i njohur si një API RESTful. Në një API REST, çdo pjesë e të dhënave trajtohet si një burim dhe i jepet një identitet i veçantë standard i burimit (URI).
Për shembull, API Twitter e bën çdo cicërim një burim të rikuperueshëm që është i disponueshëm për klientët. Twitter API mund të përdoret nga përdoruesit për të postuar cicërima dhe për të kryer detyra të tjera në uebsajt.
3. Çfarë është saktësisht URI?
A rrjet kompjuterik burimi mund të referohet duke përdorur një URI ose identifikues uniform të burimit. Ai shërben si një mjet për të ndarë një burim nga një tjetër. Burimet mund të jenë ose jo në internet.
Për shkak të strukturës së tyre standarde, URI-të e bëjnë të thjeshtë lidhjen edhe me lloje të ndryshme burimesh. Vendndodhja ose emri i burimit përfshihet në URI së bashku me një varg karakteresh.
URI përbëhet nga një shteg, skemë, pyetje dhe elementë të tjerë, por nuk përfshin protokollin.
Duke përdorur një protokoll, URL-të (Uniform Resource Locators) përdoren për të gjetur burime në internet ose të aksesueshme nëpërmjet tij.
4. Cilat janë karakteristikat e RESTful Web Services?
- Paradigma Klient-Server është themeli i shërbimit.
- Shërbimi mund të aksesojë burimet duke përdorur URI-të.
- Shërbimi përdor Protokollin HTTP për të marrë të dhëna/burime, për të drejtuar pyetje dhe për të kryer detyra të tjera.
- Mesazhimi është emri i metodës së përdorur për të komunikuar ndërmjet klientit dhe serverit.
- Këto shërbime mund të zbatojnë gjithashtu modelin arkitektonik REST duke përdorur shërbimet SOAP.
- Për të reduktuar thirrjet e serverëve për të njëjtin lloj kërkesash të përsëritura, këto shërbime përdorin gjithashtu idenë e caching.
5. Cilat janë parimet drejtuese të REST?
Pesë kritere duhet të plotësohen nga API-të REST:
Shkëputja klient-server: Vetëm një seri kërkesash dhe përgjigjesh mund të përdoren për të komunikuar ndërmjet klientit dhe serverit. Vetëm klientët dhe serverët janë në gjendje të dërgojnë përkatësisht kërkesa dhe përgjigje. Kjo ide e drejtpërdrejtë u mundëson të dyja palëve të funksionojnë të pavarur nga njëra-tjetra.
Ndërfaqja uniforme: Duhet të ketë një protokoll uniform për të gjitha lidhjet klient-server. Ky protokoll për REST është HTTP. Për shkak se çdo aplikacion kërkon dhe dërgon të dhëna duke përdorur të njëjtën gjuhë, një ndërfaqe e qëndrueshme i bën integrimet më të thjeshta.
Pa shtetësi: Serveri nuk ruan asnjë regjistrim të kërkesave ose përgjigjeve të mëparshme në komunikimin pa shtetësi. Çdo kërkesë dhe përgjigje ofron të gjitha detajet e kërkuara për të përfunduar shkëmbimin. Komunikimi pa shtetësi rrit shpejtësinë, kursen kujtesën dhe pakëson stresin në server. Për më tepër, ai shmang mundësinë e dështimit të një kërkese për shkak të të dhënave jo të plota.
Sistemi me shtresa: Serverët që qëndrojnë midis klientit dhe serverit API quhen shtresa. Këta serverë shtesë kryejnë një sërë shërbimesh, të tilla si zbulimi i spamit dhe optimizimi i shpejtësisë. Shtresat në REST janë modulare, që do të thotë se ato mund të shtohen dhe fshihen pa ndikuar në komunikimet midis klientit dhe serverit API.
Cacheable: Klientët mund të ruajnë çdo burim për të rritur shpejtësinë nëse përgjigjet e serverit tregojnë nëse burimi është i disponueshëm ose jo.
Kodimi sipas kërkesës: Si përgjigje, një API mund të transmetojë kodin kompjuterik të ekzekutueshëm te klientët. Aplikacioni i klientit më pas mund ta ekzekutojë kodin në anën e tij të pasme.
6. Përmendni metodat HTTP që mbështet REST.
Metodat HTTP që mbështet REST janë:
- GET: Kjo metodë kërkon një burim në URL-në e specifikuar. Një organ i kërkesës nuk duhet të përfshihet sepse do të shpërfillet. Mund të jetë e mundur që të ruhet në memorie lokale ose në server.
- POST: Kjo metodë dërgon të dhëna në një shërbim për përpunim dhe shërbimi duhet të kthejë normalisht një burim të ri ose të ndryshuar.
- PUT: Burimi përditësohet në URL-në e kërkesës.
- FSHIJE: Burimi fshihet në URL-në e kërkesës.
- Opsionet: Identifikon metodat e mbështetura.
- HEAD: Meta të dhënat e URL-së së kërkesës janë kthyer.
7. Përshkruani kufizimet e vendosura nga një ndërfaqe konsistente.
Për të ndarë klientin nga serveri, kërkohet një ndërfaqe e qëndrueshme.
Për të arritur një ndërfaqe të qëndrueshme, kërkohen katër kufizimet e mëposhtme:
- Identifikimi i burimit: Kërkesat e klientit duhet të përdorin ID standarde të burimeve për të identifikuar burimet (URI)
- Manipulimi i burimeve duke përdorur këto paraqitje: Klientët kanë të gjithë informacionin e kërkuar për të qenë në gjendje të ndryshojnë gjendjen e burimit kur marrin një përfaqësim të burimit nga serveri.
- Mesazhe vetëpërshkruese: Mesazhet përfshijnë të gjitha meta të dhënat dhe informacionet e tjera që kërkohen që marrësi t'i kuptojë ato.
- Hipermedia si motori i gjendjes së aplikacionit: Kanali për komunikimin klient-server është hipermedia, siç është HTML, dhe klientët nuk kanë nevojë për dokumentacion specifik të API-së për të kuptuar përgjigjet e serverit.
8. Çfarë është saktësisht një Burim REST?
Burimet janë komponentët themelorë të një shërbimi në internet RESTful në një arkitekturë REST. Ato përfshijnë të gjitha informacionet thelbësore që duhet të ketë një klient API.
Çdo lloj burimi, si një faqe HTML, një imazh, një video ose çdo gjë tjetër që nevojitet për një aktivitet API, mund të aksesohet përmes serverit në një sistem klient-server.
Burimet identifikohen nga një Identifikues Uniform i Burimeve. Teksti, JSON ose XML janë të gjitha përfaqësime të pranueshme të burimeve. Duke u shprehur kështu, nuk ka kufizime në formatin e përfaqësimit.
9. Çfarë do të thotë JAX-RS për ju?
Është më e thjeshtë të krijosh shërbime uebi RESTful në Java falë Java API për Shërbimet e Uebit RESTful, të njohura shpesh si JAX-RS. Zhvilluesit mund të përshkruajnë burimet dhe operacionet që mund të kryhen mbi to duke përdorur shënimet që jepen.
10. Çfarë i dallon AJAX-in dhe REST-in nga njëri-tjetri?
Ajax:
- Ajax është një grup teknologjish që lejon përditësimin dinamik të Ndërfaqja e përdoruesit elementet pa pasur nevojë të ringarkoni faqen.
- Ajax heq komunikimin asinkron midis klientit dhe serverit.
PUSHIMI:
- REST kërkon komunikim ndërmjet serverit dhe klientit.
- Përdorimi i burimeve është i rëndësishëm për strukturën e URL-së dhe modelin e kërkesës/përgjigjes së përdorur nga REST.
11. A mund të listoni disa të meta të shërbimeve të uebit RESTful?
Seancat nuk mund të mbahen pasi shërbimet i përmbahen nocionit të pashtetësisë. (Klienti është përgjegjës për kalimin e ID-së së sesionit gjatë gjithë simulimit të seancës.)
Kufizimet e sigurisë nuk janë thelbësore për REST. Protokollet që e përdorin atë trashëgojnë masat paraprake të sigurisë. Prandaj, marrja e kujdesit gjatë vendosjes së masave të sigurisë, si integrimi i vërtetimeve të bazuara në SSL/TLS, është i rëndësishëm.
12. Çfarë i dallon teknikat PUT dhe POST nga njëra-tjetra?
VENDOSI:
- Nuk ka cache për përgjigjet PUT.
- Idempotent (dmth kërkesat e shumta do të japin të njëjtin rezultat)
- ngarkesa e kërkesës përditëson ose zëvendëson burimin e synuar.
POST:
- idempotent jo (d.m.th., kërkesa të shumta do të japin shumëfisha të të njëjtit burim)
- Ueb serveri përpunon ngarkesën e kërkesës bazuar në burimin e synuar.
- Nëse përfshihet titulli i duhur i kontrollit të cache-it, përgjigjet POST mund të ruhen në memorie.
13. Si i testoni shërbimet e internetit RESTful?
Testimi i shërbimit në internet RESTful mund të ndihmohet nga një sërë mjetesh, duke përfshirë Swagger dhe Postman. Inspektimi i parametrave të kërkesës si parametrat e pyetjes, titujt dhe titujt e përgjigjeve mundësohet nga bollëku i veçorive të këtyre të fundit.
Postman mund të përdoret për të bërë kërkesa në pikat fundore dhe për të treguar rezultatet. Dhe XML dhe JSON mund të krijohen nga këto përgjigje.
Postman dhe Swagger ofrojnë funksione jashtëzakonisht të krahasueshme. Nga ana tjetër, Swagger ofron gjithashtu aftësi si dokumentacioni i pikës fundore.
14. Përshkruani një API REST në botën reale.
- Uebsajtet e udhëtimit dhe biletave mund të përdorin oraret dhe çmimet e fluturimeve që linjat ajrore i vënë në dispozicion përmes API-ve.
- Në mënyrë që aplikacionet e hartës dhe navigimit (si Google Maps) t'i përdorin ato, agjencitë e transportit publik shpesh i bëjnë të dhënat e tyre të disponueshme publikisht në kohë reale nëpërmjet API-ve.
- Aplikacionet e motit përdorin API të hapura që shkëmbejnë të dhënat e motit për të shfaqur informacionin e motit.
- Zhvilluesit mund të kenë qasje në të dhënat e hartës së Google Maps nëpërmjet një numri të API-ve të tij të pritura. Këto API përdoren nga zhvilluesit për të futur harta dinamike në aplikacionet dhe faqet e tyre të internetit.
15. Si funksionon Arkitektura Microservice?
- Kërkesat dërgohen nga klientë të ndryshëm duke përdorur pajisje të ndryshme.
- Pas konfirmimit të identitetit të klientëve, ofruesit e identitetit ofrojnë shenja sigurie.
- Kërkesat e klientit menaxhohen nga API Gateway.
- I gjithë materiali i sistemit ruhet si përmbajtje statike.
- Mjeti i menaxhimit kontrollon balancën e shërbimeve në nyje dhe çdo defekt.
- Zbulimi i rrugës së komunikimit ndërmjet mikroshërbimeve ndihmohet nga zbulimi i shërbimit.
- Qendrat e të dhënave dhe serverët proxy përbëjnë sisteme rrjeti të shpërndara të quajtura rrjete të shpërndarjes së përmbajtjes.
- Shërbimet në distancë ofrojnë qasje në informacion nga distanca.
16. Çfarë saktësisht është caching?
Praktika e mbajtjes së përkohshme të një kopjeje të përgjigjes së serverit diku (siç është memoria e kompjuterit) me qëllim që të aksesohet më vonë më shpejt, njihet si memoria e fshehtë.
Caching rrit shpejtësinë e serverit kur përdorni API-të REST duke ulur sasinë e punës që serveri duhet të bëjë për të kënaqur kërkesën. Aplikacionet që përdorin API-në funksionojnë më shpejt falë ruajtjes në memorie, sepse nuk duhet të paraqesin një kërkesë të re sa herë që u nevojitet një burim.
Fusha "Cache-Control" e titullit të përgjigjes HTTP përmban informacione për sa kohë mund të ruhet një burim nga klienti përpara se të duhet të aksesohet përsëri.
17. Përshkruani ngarkesën.
Ngarkesa në REST i referohet informacionit që gjendet në trupin e përgjigjes HTTP. Klienti përdori teknikën GET për të kërkuar të dhënat në fjalë.
Dokumenti që përmban tekstin e tweet-it dhe çdo skedar të nevojshëm për vendosjen e tweet-it në një faqe interneti do të përfshihet në ngarkesën, për shembull, nëse kërkoni nga API-ja e Twitter për një cicërimë specifike. Për më tepër, ngarkesa mund të përfshihet në kërkesën HTTP duke përdorur metodën POST.
18. Diferenconi SOAP Vs REST?
- Ndryshe nga SOAP, i cili mund të trajtojë vetëm XML, REST mundëson një gamë më të gjerë të formateve të burimeve, duke përfshirë XML, tekst, HTML, fotografi, video dhe më shumë.
- Kur siguria është thelbësore për aplikacionet në internet, SOAP është i dobishëm. REST nuk mund të përdoret kur transaksionet duhet të përfundojnë në mënyrë të sigurt pasi nuk është veçanërisht i sigurt.
- Meqenëse SOAP është vetëm një protokoll, REST mund ta përdorë atë në shërbimet e tij të internetit, por jo anasjelltas.
- Ndërsa REST është vetëm një model arkitektonik i përdorur për të zhvilluar shërbime në internet dhe i përmbahet disa kufizimeve të tilla si konfigurimi i serverit-klient, pashtetësia, përgjigja e cacheable, sistemet me shtresa dhe ndërfaqja e qëndrueshme, SOAP është një protokoll që funksionon sipas standardeve të veçanta që duhet të respektohen me rigorozitet. te.
- Ndërsa REST përdor identifikuesit universal të burimeve (URIs), SOAP përdor ndërfaqet e shërbimit për të ofruar aftësitë e tij për aplikacionet e klientit. REST ka një nevojë më të ulët për gjerësi brezi sesa SOAP pasi mesazhet SOAP janë më të rënda për informacion.
19. A mund të përdoret protokolli i sigurisë së shtresës së transportit (TLS) me REST?
Në fakt, ne mundemi. Komunikimi i klientit dhe serverit REST është i koduar përmes TLS, dhe protokolli gjithashtu u jep klientëve një mënyrë për të vërtetuar serverët.
Për shkak të faktit se është zëvendësues i Secure Socket Layer, ai përdoret për komunikim të sigurt (SSL). Zbatimi i shërbimeve të uebit RESTful është i suksesshëm me HTTPS sepse bashkëpunon në mënyrë efektive si me TLS ashtu edhe me SSL.
REST trashëgon karakteristikat e protokollit që zbaton, gjë që është një gjë që duhet theksuar këtu. Si rezultat, mbrojtjet e sigurisë varen nga protokolli që përdor REST.
20. Metodat idempotente: cilat janë ato? Si zbatohet në botën e shërbimeve të internetit RESTful?
Kur URI është i njëjtë, disa metoda HTTP në një kërkesë kanë të njëjtin ndikim në server nëse ato dorëzohen një herë ose disa herë. Teknikat idempotente njihen si këto.
Për shembull, pavarësisht se sa herë ekzekutohet një URI që përdor metodën GET, serveri do të përjetojë gjithmonë të njëjtin rezultat. Metodat idempotente përfshijnë GET, PUT dhe PATCH, për të përmendur disa.
Metodat idempotente HTTP janë disa nga ato të përdorura nga RESTful aplikacione në internet. Ato janë të nevojshme për të garantuar qëndrueshmëri në aktivitetet e shërbimeve të internetit RESTful.
Klientët që përdorin API-të REST mund të bëjnë gabime kodi që detyrojnë një API REST të bëjë kërkesa të përsëritura aksidentalisht. Këto thirrje kanë potencial për të keqpërdorur burimet.
21. Cili është funksionaliteti i Autentifikimit Bazë HTTP?
Kur përdorni Autentifikimin Bazë si pjesë e API-ve, përdoruesi duhet të paraqesë emrin e përdoruesit dhe fjalëkalimin, të cilat janë të lidhura nga shfletuesi në formën "emri i përdoruesit: fjalëkalimi" dhe i koduar bazë64.
Në çdo kërkesë HTTP nga shfletuesi, vlera e koduar dorëzohet si vlerë për kokën "Autorizimi". Për shkak se kredencialet janë thjesht të koduara, rekomandohet përdorimi i këtij formulari kur dërgoni kërkesa HTTPS sepse ato nuk janë të sigurta dhe mund të përgjohen nga kushdo nëse nuk përdoren protokollet e sigurisë.
22. A mendoni se GraphQL është zgjidhja më e mirë për krijimin e arkitekturës së mikroservisit?
Microservices dhe GraphQL shkojnë në mënyrë perfekte sepse GraphQL e mban sekret arkitekturën tuaj të mikroshërbimit nga klientët tuaj.
Nga pjesa e përparme, dëshironi që të gjitha të dhënat tuaja të vijnë nga një API e vetme, ndërsa nga pjesa e pasme, dëshironi t'i ndani në mikroshërbime. Teknika më e mirë që unë jam në dijeni për të arritur të dyja është duke përdorur GraphQL.
Kjo ju mundëson të ndani backend-in tuaj në mikroshërbime, ndërkohë që i jepni çdo aplikacioni një API të vetme dhe mundëson bashkime të të dhënave nga shërbime të ndryshme.
23. Cilat janë dallimet kryesore ndërmjet metodave HTTP të sigurta dhe idempotente?
Metodat idempotente prodhojnë të njëjtin rezultat kur thirren një ose disa herë përmes së njëjtës kërkesë. Metoda PUT është idempotente.
Të gjitha mënyrat e sigurta janë idempotente, por jo të gjitha metodat idempotente janë të sigurta pasi metodat e sigurta nuk i ndryshojnë burimet. Për shembull, GET është i sigurt pasi thjesht merr të dhëna dhe nuk ndryshon burimin.
Për më tepër, është idempotent, që do të thotë se gjithmonë do të kthejë të njëjtën përgjigje kur thirret.
24. Çfarë nënkupton JAX-RS API nga RESTful Root Resource Classes?
Java Enterprise Edition ofron klasa dhe ndërfaqe që i përmbahen kërkesave të JAX-RS API. Me ndihmën e JAX-RS, krijimi i shërbimeve në internet Java në stilin arkitektonik REST është bërë më i lehtë.
Në JAX-RS API, klasat e burimeve rrënjësore janë thjesht "objekte të thjeshta të vjetra java" ose POJO. Për të zbatuar burimet e nevojshme të uebit, ata përdorin shënime JAX-RS.
Ata ose kanë shënime @path ose të paktën një nga metodat e tyre ka shënime @path. Ato mund të përmblidhen si klasa Java me metoda për trajtimin e pikave fundore të API.
25. Çfarë është saktësisht Postman dhe pse përdoret?
Një mjet zhvillimi API i quajtur Postman përdoret për të krijuar, testuar dhe modifikuar API-të. Ky mjet mund të përdoret nga zhvilluesit për çfarëdo veçori që ata kërkojnë për një API. Ai thjeshton dhe lehtëson punën e zhvilluesve.
Postman e bën të lehtë krijimin e një sërë pyetjesh HTTP, duke përfshirë GET, POST, PUT dhe PATCH, ruajtjen e mjediseve për përdorim të mëvonshëm dhe konvertimin e API-ve në kod në një numër gjuhësh të ndryshme.
Çdo fazë e ciklit API është bërë më e thjeshtë me Postman dhe bashkëpunimi është i efektshëm për zhvillim më të shpejtë të API.
Për më tepër, ai u mundëson zhvilluesve të menaxhojnë dokumentacionin, specifikimet, rastet e testimit, proceset dhe katalogët API.
26. Si mbahen të sigurta API-të REST?
Meqenëse API-të REST nuk përdorin masa mbrojtëse të rrepta sigurie si API-të e SOAP, të dhënat e ndjeshme nuk duhet të dërgohen ose të merren duke përdorur ato.
Megjithatë, API-të e besueshme REST vazhdojnë të integrojnë kontrollet e sigurisë për transmetime të sigurta dhe të besueshme të të dhënave.
- Autentifikimi dhe autorizimi: Çdo kërkesë e bërë në API duhet të kalojë këto dy kontrolle. Verifikimi i identitetit të klientit përmes vërtetimit dhe vërtetimi se ata kanë autoritet për të hyrë në burimet e kërkuara përmes autorizimit janë dy procese të ndryshme.
- Vleresimi: Përpara se API të japë akses në burimet e tij, kërkesat duhet të kontrollohen përsëri për kodin e mundshëm të dëmshëm pas vërtetimit dhe autorizimit. Kështu, një server do të ishte i hapur ndaj një sulmi injeksion.
- Vleresimi: Përpara se API të japë akses në burimet e tij, kërkesat duhet të kontrollohen përsëri për kodin e mundshëm të dëmshëm pas vërtetimit dhe autorizimit. Kështu, një server do të ishte i hapur ndaj një sulmi injeksion.
- Kriptimi: Kriptimi TLS/SSL mbron lidhjen midis klientit dhe serverit dhe i mban hakerët të mos përgjojnë kërkesat dhe përgjigjet.
- Teknikat e kufizimit të normës, të tilla si kufijtë dhe mbytja, mbrojnë serverët nga sulmet me forcë brutale si DDoS që synojnë t'i degradojnë ose rrëzojnë ato.
- Nuk ka informacion të ndjeshëm në URI: URI-të e burimeve nuk duhet të përmbajnë asnjë të dhënë të mbrojtur (si p.sh. një emër përdoruesi, fjalëkalim ose token vërtetimi).
Përfundim
urime! Disa pyetje themelore deri në komplekse të intervistës REST API dhe zgjidhjet e tyre përkatëse janë tani në majë të gishtave tuaj.
Tani që keni një koncept të mirë se si t'i përgjigjeni disa prej pyetjeve tipike të intervistës REST API, mund të vazhdoni t'u përgjigjeni intervistave. Hapi tjetër varet nga objektivat tuaja.
vizitë Seria e intervistave me Hashdork për t'u përgatitur për intervista.
Lini një Përgjigju