Sisällysluettelo[Piilottaa][Näytä]
- 1. Mitä ymmärrät REST:llä?
- 2. Mitä tarkoitat REST API:lla?
- 3. Mikä URI oikein on?
- 4. Mitkä ovat RESTful Web Services -palvelun ominaisuudet?
- 5. Mitkä ovat RESTin ohjaavat periaatteet?
- 6. Mainitse RESTin tukemat HTTP-menetelmät.
- 7. Kuvaile johdonmukaisen rajapinnan asettamia rajoituksia.
- 8. Mikä REST-resurssi oikein on?
- 9. Mitä JAX-RS tarkoittaa sinulle?
- 10. Mikä erottaa AJAXin ja RESTin toisistaan?
- 11. Voitko luetella joitain RESTful-verkkopalveluiden haittoja?
- 12. Mikä erottaa PUT- ja POST-tekniikat toisistaan?
- 13. Kuinka testaat RESTful-verkkopalveluita?
- 14. Kuvaile REST-sovellusliittymää todellisessa maailmassa.
- 15. Miten mikropalveluarkkitehtuuri toimii?
- 16. Mitä välimuisti tarkalleen ottaen on?
- 17. Kuvaile hyötykuormaa.
- 18. Erottaako SOAP vs REST?
- 19. Voidaanko TLS-suojausprotokollaa käyttää RESTin kanssa?
- 20. Idempotentit menetelmät: mitä ne ovat? Miten se pätee RESTful-verkkopalveluiden maailmaan?
- 21. Mikä on HTTP-perustodennuksen toiminnallisuus?
- 22. Onko GraphQL mielestäsi paras valinta mikropalveluarkkitehtuurin luomiseen?
- 23. Mitkä ovat tärkeimmät erot turvallisen ja idempotentin HTTP-menetelmien välillä?
- 24. Mitä JAX-RS API tarkoittaa RESTful Root Resource Classes -luokissa?
- 25. Mikä Postimies oikein on ja miksi sitä käytetään?
- 26. Miten REST API:t pidetään turvassa?
- Yhteenveto
RESTin kehitys on tehnyt API:t uskomattoman helposti saavutettavissa ja paljastanut samalla niiden täyden vahvuuden ja potentiaalin. REST-sovellusliittymiä on helppo luoda ja tallentaa välimuistiin niiden resurssisuuntautuneen arkkitehtuurin vuoksi.
Lisäksi RESTful API:t olivat kautta aikojen edelläkävijöitä muissa merkittävissä kehityssuunnissa, kuten pilvipalveluissa ja mikropalvelupohjaisessa suunnittelussa.
Siksi ei pitäisi olla yllättävää, että REST API -kehittäjät ovat nykyään kysyttyjä, koska he tarjoavat RESTful-palveluita käyttäville yrityksille kilpailuetua. REST API:t ovat suosittu suunnittelutrendi.
Monet IT-yritykset haluavat REST API -tietoa ohjelmistokehittäjiä ja kysy siitä teknisissä haastatteluissa.
Tässä on joitain tyypillisimpiä REST API -haastattelukysymyksiä, jotka auttavat sinua olemaan valmiita haastatteluihin eri yrityksissä, jos haluat työskennellä REST API -kehityskentällä.
1. Mitä ymmärrät REST:llä?
REST on arkkitehtoninen paradigma web-pohjaisten sovellusten suunnitteluun, jotka perustuvat HTTP-protokollaan (Hypertext Transfer Protocol).
REST määrittelee tietyt standardit, jotka verkkopalvelujen on täytettävä, jotta niitä voidaan pitää RESTfulina. Nämä suositukset takaavat, että pyynnöt ja resurssit siirretään nopeasti ja tehokkaasti asiakkaan ja palvelimen välillä käyttämällä standardoituja HTTP-protokollia.
2. Mitä tarkoitat REST API:lla?
Ohjelmisto-ohjelmisto-linkki, joka tunnetaan nimellä sovellusohjelmointirajapinta, mahdollistaa viestinnän ja tiedon jakamisen muuten itsenäisten ohjelmien välillä. Esimerkiksi uutissivusto voisi käyttää Twitter-sovellusliittymää löytääkseen asiaankuuluvat twiitit automaattisesti ja integroidakseen ne uutisjuttuihin.
REST-periaatteita noudattava API tunnetaan nimellä REST API, joka tunnetaan joskus myös nimellä RESTful API. REST-sovellusliittymässä kutakin dataa käsitellään resurssina ja niille annetaan erillinen vakioresurssitunnus (URI).
Esimerkiksi Twitter API tekee jokaisesta twiitistä palautettavan resurssin, joka on asiakkaiden käytettävissä. Käyttäjät voivat käyttää Twitter-sovellusliittymää tweettien lähettämiseen ja muiden verkkosivustotehtävien suorittamiseen.
3. Mikä URI oikein on?
A tietokoneverkko resurssiin voidaan viitata käyttämällä URI:ta tai yhtenäistä resurssitunnusta. Se toimii keinona erottaa yksi resurssi toisesta. Lähteet voivat olla verkossa tai eivät.
Standardirakenteensa ansiosta URI:t helpottavat yhteyden muodostamista jopa erilaisiin resursseihin. Resurssin sijainti tai nimi sisällytetään URI:ihin merkkijonon kanssa.
URI koostuu polusta, skeemasta, kyselystä ja muista elementeistä, mutta se ei sisällä protokollaa.
Protokollan avulla URL-osoitteita (Uniform Resource Locators) käytetään etsimään resursseja Internetistä tai saatavilla sen kautta.
4. Mitkä ovat RESTful Web Services -palvelun ominaisuudet?
- Asiakas-palvelin -paradigma on palvelun perusta.
- Palvelu voi käyttää resursseja URI:iden kautta.
- Palvelu käyttää HTTP-protokollaa tietojen/resurssien hankkimiseen, kyselyjen suorittamiseen ja muiden tehtävien suorittamiseen.
- Viestit ovat asiakkaan ja palvelimen välisessä viestinnässä käytetyn menetelmän nimi.
- Nämä palvelut voivat myös toteuttaa REST-arkkitehtuurimallin SOAP-palveluiden avulla.
- Samanlaisten toistuvien pyyntöjen palvelinkutsujen vähentämiseksi nämä palvelut käyttävät myös ajatusta välimuistista.
5. Mitkä ovat RESTin ohjaavat periaatteet?
REST-sovellusliittymien on täytettävä viisi kriteeriä:
Asiakas-palvelin irrotus: Asiakkaan ja palvelimen väliseen viestintään voidaan käyttää vain sarjaa pyyntöjä ja vastauksia. Vain asiakkaat ja palvelimet voivat lähettää pyyntöjä ja vastauksia. Tämä yksinkertainen idea mahdollistaa sen, että molemmat osapuolet voivat toimia toisistaan riippumatta.
Yhtenäinen käyttöliittymä: Kaikille asiakas-palvelin-yhteyksille on oltava yhtenäinen protokolla. Tämä REST-protokolla on HTTP. Koska jokainen sovellus pyytää ja lähettää tietoja samalla kielellä, yhtenäinen käyttöliittymä tekee integroinnista yksinkertaisempaa.
Tilaton: Palvelin ei tallenna tietueita aiemmista pyynnöistä tai vastauksista tilattomassa viestinnässä. Jokaisessa pyynnössä ja vastauksessa on kaikki vaihdon suorittamiseen tarvittavat tiedot. Tilaton viestintä lisää nopeutta, säästää muistia ja vähentää palvelimen stressiä. Lisäksi se välttää pyynnön epäonnistumisen epätäydellisten tietojen vuoksi.
Kerrosjärjestelmä: Palvelimia, jotka sijaitsevat asiakkaan ja API-palvelimen välillä, kutsutaan tasoiksi. Nämä lisäpalvelimet suorittavat erilaisia palveluita, kuten roskapostin havaitsemisen ja nopeuden optimoinnin. REST-tasot ovat modulaarisia, mikä tarkoittaa, että niitä voidaan lisätä ja poistaa vaikuttamatta asiakkaan ja API-palvelimen väliseen viestintään.
Välimuistiin tallennettava: Asiakkaat voivat tallentaa kaikki resurssit välimuistiin nopeuden lisäämiseksi, jos palvelimen vastaukset osoittavat, onko resurssi välimuistissa vai ei.
On-demand-koodaus: Vastauksena API voi lähettää suoritettavan tietokonekoodin asiakkaille. Asiakassovellus voi sitten suorittaa koodin omassa taustassaan.
6. Mainitse RESTin tukemat HTTP-menetelmät.
RESTin tukemat HTTP-menetelmät ovat:
- GET: Tämä menetelmä pyytää resurssia määritetyssä URL-osoitteessa. Pyynnön runkotekstiä ei pitäisi sisällyttää, koska se ohitetaan. Se voi olla mahdollista tallentaa välimuistiin paikallisesti tai palvelimella.
- POST: Tämä menetelmä lähettää tiedot palveluun käsittelyä varten, ja palvelun pitäisi normaalisti palauttaa uusi tai muutettu resurssi.
- PUT: Resurssi päivitetään pyynnön URL-osoitteeseen.
- DELETE: Resurssi poistetaan pyynnön URL-osoitteesta.
- Asetukset: Se tunnistaa tuetut menetelmät.
- HEAD: Pyynnön URL-osoitteen metatiedot palautetaan.
7. Kuvaile johdonmukaisen rajapinnan asettamia rajoituksia.
Asiakkaan erottamiseksi palvelimesta tarvitaan johdonmukainen käyttöliittymä.
Johdonmukaisen käyttöliittymän saavuttamiseksi vaaditaan seuraavat neljä rajoitusta:
- Resurssin tunnistaminen: Asiakaspyyntöjen on käytettävä standardeja resurssitunnuksia resurssien tunnistamiseen (URI)
- Resurssien manipulointi käyttämällä näitä esityksiä: Asiakkailla on kaikki tarvittavat tiedot voidakseen muuttaa resurssin tilaa, kun he saavat resurssiesityksen palvelimelta.
- Itsekuvaavat viestit: Viestit sisältävät kaikki metatiedot ja muut tiedot, joita vastaanottaja tarvitsee ymmärtääkseen ne.
- Hypermedia sovelluksen tilamoottorina: Asiakas-palvelin-viestinnän kanava on hypermedia, kuten HTML, eivätkä asiakkaat tarvitse API-kohtaista dokumentaatiota ymmärtääkseen palvelimen vastauksia.
8. Mikä REST-resurssi oikein on?
Resurssit ovat RESTful-verkkopalvelun peruskomponentteja REST-arkkitehtuurissa. Ne sisältävät kaikki olennaiset tiedot, joita API-asiakkaan on käytettävä.
Kaikenlaisia resursseja, kuten HTML-sivua, kuvaa, videota tai mitä tahansa muuta API-toimintaan tarvittavaa, voidaan käyttää asiakas-palvelin-järjestelmän palvelimen kautta.
Resurssit tunnistetaan Uniform Resource Identifier -tunnuksella. Teksti, JSON tai XML ovat kaikki hyväksyttäviä resurssien esityksiä. Tämän toteamisen jälkeen esityksen muodossa ei ole rajoituksia.
9. Mitä JAX-RS tarkoittaa sinulle?
RESTful-verkkopalveluiden luominen Javassa on yksinkertaisempaa, kiitos Java API for RESTful web Services, joka tunnetaan usein nimellä JAX-RS. Kehittäjät voivat kuvata resursseja ja niille suoritettavia toimintoja käyttämällä annettuja huomautuksia.
10. Mikä erottaa AJAXin ja RESTin toisistaan?
Ajax:
- Ajax on joukko teknologioita, jotka mahdollistavat dynaamisen päivityksen käyttöliittymä elementtejä tarvitsematta ladata sivua uudelleen.
- Ajax poistaa asynkronisen tiedonsiirron asiakkaan ja palvelimen välillä.
LEVÄTÄ:
- REST vaatii viestintää palvelimen ja asiakkaan välillä.
- Resurssien käyttö on tärkeää RESTin käyttämän URL-rakenteen ja pyyntö/vastausmallin kannalta.
11. Voitko luetella joitain RESTful-verkkopalveluiden haittoja?
Istuntoja ei voida pitää yllä, koska palvelut noudattavat kansalaisuudettomuuden käsitettä. (Asiakas vastaa istunnon tunnuksen välittämisestä koko istunnon simulaation ajan.)
Turvallisuusrajoitukset eivät ole RESTin perustavanlaatuisia. Sitä käyttävät protokollat perivät turvatoimet. Siksi on tärkeää noudattaa varovaisuutta turvatoimien, kuten SSL/TLS-pohjaisten todennusten integroinnin, käyttöönotossa.
12. Mikä erottaa PUT- ja POST-tekniikat toisistaan?
LAITTAA:
- PUT-vastauksille ei ole välimuistia.
- Idempotentti (eli useat pyynnöt antavat saman tuloksen)
- pyynnön hyötykuorma päivittää tai korvaa kohderesurssin.
LÄHETTÄÄ:
- idempotent not (eli useat pyynnöt tuottavat saman resurssin kerrannaisia)
- Verkkopalvelin käsittelee pyynnön hyötykuorman aiotun resurssin perusteella.
- Jos sopiva välimuistin ohjausotsikko on mukana, POST-vastaukset voidaan tallentaa välimuistiin.
13. Kuinka testaat RESTful-verkkopalveluita?
RESTful-verkkopalvelutestausta voidaan auttaa useilla työkaluilla, kuten Swaggerilla ja Postmanilla. Pyyntöparametrien, kuten kyselyparametrien, otsikoiden ja vastausotsikoiden, tarkastamisen tekee mahdolliseksi jälkimmäisen ominaisuuksien runsaus.
Postmanilla voidaan tehdä pyyntöjä päätepisteille ja näyttää tulokset. Ja XML ja JSON voidaan luoda näistä vastauksista.
Postman ja Swagger tarjoavat molemmat erittäin vertailukelpoisia toimintoja. Toisaalta Swagger tarjoaa myös ominaisuuksia, kuten päätepisteiden dokumentoinnin.
14. Kuvaile REST-sovellusliittymää todellisessa maailmassa.
- Matkailu- ja lippusivustot voivat hyödyntää lentojen aikatauluja ja hintoja, jotka lentoyhtiöt tarjoavat sovellusliittymien kautta.
- Jotta kartta- ja navigointisovellukset (kuten Google Maps) voisivat käyttää niitä, joukkoliikennetoimistot tuovat usein tietonsa julkisesti saataville reaaliajassa API:iden kautta.
- Sääsovellukset käyttävät avoimia sovellusliittymiä, jotka vaihtavat säätietoja näyttääkseen säätietoja.
- Kehittäjät voivat käyttää Google Mapsin karttatietoja useiden sen isännöimien sovellusliittymien kautta. Kehittäjät käyttävät näitä sovellusliittymiä dynaamisten karttojen upottamiseen sovelluksiinsa ja verkkosivustoihinsa.
15. Miten mikropalveluarkkitehtuuri toimii?
- Eri asiakkaat lähettävät pyyntöjä eri laitteilla.
- Asiakkaiden henkilöllisyyden vahvistamisen jälkeen identiteetintarjoajat tarjoavat suojaustunnukset.
- Asiakaspyyntöjä hallinnoi API Gateway.
- Kaikki järjestelmän materiaali säilyy staattisena sisältönä.
- Hallintatyökalu tarkistaa palvelujen tasapainon solmuissa ja mahdolliset viat.
- Mikropalvelujen välisen kommunikaatiopolun löytämistä auttaa palvelun löytäminen.
- Datakeskukset ja välityspalvelimet muodostavat hajallaan olevia verkkojärjestelmiä, joita kutsutaan sisällönjakeluverkoiksi.
- Etäpalvelut tarjoavat tiedon pääsyn etäältä.
16. Mitä välimuisti tarkalleen ottaen on?
Käytäntöä säilyttää kopio palvelimen vastauksesta tilapäisesti jossain (kuten tietokoneen muistissa), jotta sitä voidaan käyttää myöhemmin nopeammin, tunnetaan välimuistina.
Välimuisti lisää palvelimen nopeutta käytettäessä REST-sovellusliittymiä vähentämällä työtä, joka palvelimen on tehtävä pyynnön täyttämiseksi. Sovellusliittymää käyttävät sovellukset toimivat nopeammin välimuistin ansiosta, koska niiden ei tarvitse lähettää uutta pyyntöä joka kerta, kun he tarvitsevat resurssia.
HTTP-vastausotsikon Cache-Control-kenttä sisältää tietoja siitä, kuinka kauan asiakas voi säilyttää resurssin välimuistissa ennen kuin sitä on käytettävä uudelleen.
17. Kuvaile hyötykuormaa.
REST:n hyötykuorma viittaa HTTP-vastauksen runkoon sisältyviin tietoihin. Asiakas käytti GET-tekniikkaa kyseisten tietojen pyytämiseen.
Asiakirja, joka sisältää twiitin tekstin ja kaikki tarvittavat tiedostot twiitin sijoittamiseen verkkosivustolle, sisällytetään hyötykuormaan, jos esimerkiksi kysyt Twitter-sovellusliittymältä tiettyä twiittiä. Lisäksi hyötykuorma voidaan sisällyttää HTTP-pyyntöön käyttämällä POST-menetelmää.
18. Erota SOAP Vs REST?
- Toisin kuin SOAP, joka pystyy käsittelemään vain XML:ää, REST mahdollistaa laajemman valikoiman resurssimuotoja, mukaan lukien XML, teksti, HTML, kuvat, videot ja paljon muuta.
- Kun tietoturva on ratkaisevan tärkeää online-sovelluksissa, SOAP on hyödyllinen. RESTiä ei voida käyttää, kun tapahtumat on suoritettava turvallisesti, koska se ei ole erityisen turvallista.
- Koska SOAP on vain protokolla, REST voi käyttää sitä verkkopalveluissaan, mutta ei päinvastoin.
- Vaikka REST on vain arkkitehtoninen malli, jota käytetään verkkopalvelujen kehittämiseen ja joka noudattaa tiettyjä rajoituksia, kuten asiakas-palvelin-asetukset, tilattomuus, välimuistiin tallennettava vastaus, kerrostetut järjestelmät ja johdonmukainen käyttöliittymä, SOAP on protokolla, joka toimii tietyillä standardeilla, joita on noudatettava tarkasti. to.
- Kun REST käyttää URI-tunnisteita (Universal Resource Identifiers), SOAP käyttää palvelurajapintoja tarjotakseen ominaisuuksiaan asiakassovelluksille. RESTillä on pienempi kaistanleveyden tarve kuin SOAP:lla, koska SOAP-viestit ovat enemmän informaatiota vaativia.
19. Voidaanko TLS-suojausprotokollaa käyttää RESTin kanssa?
Itse asiassa voimme. REST-asiakkaan ja palvelimen viestintä on salattu TLS:n kautta, ja protokolla antaa asiakkaille myös tavan todentaa palvelimia.
Koska se on Secure Socket Layerin korvaaja, sitä käytetään suojattuun viestintään (SSL). RESTful-verkkopalveluiden käyttöönotto onnistuu HTTPS:llä, koska se toimii tehokkaasti yhteistyössä sekä TLS:n että SSL:n kanssa.
REST perii toteuttamansa protokollan ominaisuudet, mikä on tässä huomioitava asia. Tämän seurauksena tietoturvasuojat ovat riippuvaisia RESTin käyttämästä protokollasta.
20. Idempotentit menetelmät: mitä ne ovat? Miten se pätee RESTful-verkkopalveluiden maailmaan?
Kun URI on sama, joillakin pyynnön HTTP-menetelmillä on sama vaikutus palvelimeen riippumatta siitä, toimitetaanko ne kerran vai useita kertoja. Idempotentteja tekniikoita kutsutaan nimellä.
Esimerkiksi riippumatta siitä, kuinka monta kertaa GET-menetelmää käyttävä URI ajetaan, palvelin kokee aina saman tuloksen. Idempotentteja menetelmiä ovat muun muassa GET, PUT ja PATCH.
Idempotentti HTTP-menetelmiä on joitakin niistä, joita RESTful käyttää web-sovellukset. Ne ovat välttämättömiä RESTful-verkkopalveluiden toiminnan johdonmukaisuuden takaamiseksi.
Asiakkaat, jotka käyttävät REST-sovellusliittymiä, voivat tehdä koodivirheitä, jotka pakottavat REST-sovellusliittymän tekemään vahingossa toistuvia pyyntöjä. Nämä puhelut voivat käyttää resursseja väärin.
21. Mikä on HTTP-perustodennuksen toiminnallisuus?
Käytettäessä perustodennusta osana API-liittymiä, käyttäjän on toimitettava käyttäjätunnus ja salasana, jotka selain yhdistää muodossa "käyttäjätunnus: salasana" ja base64-koodattuina.
Jokaisessa selaimen HTTP-pyynnössä koodattu arvo toimitetaan "Authorization"-otsikon arvona. Koska tunnistetiedot ovat vain koodattuja, on suositeltavaa käyttää tätä lomaketta HTTPS-pyyntöjä lähetettäessä, koska ne eivät ole turvallisia ja kuka tahansa voi siepata ne, jos suojausprotokollia ei käytetä.
22. Onko GraphQL mielestäsi paras valinta mikropalveluarkkitehtuurin luomiseen?
Mikropalvelut ja GraphQL sopivat yhteen täydellisesti, koska GraphQL pitää mikropalveluarkkitehtuurisi salassa asiakkailtasi.
Etuosasta haluat kaikkien tietosi tulevan yhdestä API:sta, kun taas takaosasta haluat jakaa ne mikropalveluihin. Paras tekniikka, jonka tiedän molempien saavuttamiseksi, on GraphQL:n käyttö.
Sen avulla voit jakaa taustatietosi mikropalveluihin samalla, kun kullekin sovellukselle annetaan yksi API ja mahdollistetaan eri palveluiden tietojen yhdistäminen.
23. Mitkä ovat tärkeimmät erot turvallisen ja idempotentin HTTP-menetelmien välillä?
Idempotentit menetelmät tuottavat saman tuloksen, kun niitä kutsutaan kerran tai useita kertoja saman pyynnön kautta. PUT-menetelmä on idempotentti.
Kaikki turvalliset tavat ovat idempotentteja, mutta kaikki idempotentit menetelmät eivät ole turvallisia, koska turvalliset menetelmät eivät muuta resursseja. Esimerkiksi GET on suojattu, koska se vain hakee tiedot eikä muuta resurssia.
Lisäksi se on idempotentti, mikä tarkoittaa, että se palauttaa aina saman vastauksen, kun sitä vedetään.
24. Mitä JAX-RS API tarkoittaa RESTful Root Resource Classes -luokissa?
Java Enterprise Edition tarjoaa luokat ja rajapinnat, jotka noudattavat JAX-RS API:n vaatimuksia. JAX-RS:n avulla Java-verkkopalveluiden luominen REST-arkkitehtuurityyliin on helpompaa.
JAX-RS-sovellusliittymässä juuriresurssiluokat ovat vain "vanhoja Java-objekteja" tai POJO:ta. Tarvittavien verkkoresurssien toteuttamiseksi he käyttävät JAX-RS-merkintöjä.
Niillä on joko @path-merkinnät tai ainakin yhdessä niiden menetelmistä on @path-merkinnät. Ne voidaan tiivistää Java-luokiksi, joissa on API-päätepisteiden käsittelymenetelmiä.
25. Mikä Postimies oikein on ja miksi sitä käytetään?
API-kehitystyökalua nimeltä Postman käytetään API:iden luomiseen, testaamiseen ja muokkaamiseen. Kehittäjät voivat käyttää tätä työkalua mihin tahansa API:lle tarvitsemaansa ominaisuuteen. Se yksinkertaistaa ja helpottaa kehittäjien työtä.
Postmanin avulla on helppo tehdä erilaisia HTTP-kyselyitä, mukaan lukien GET, POST, PUT ja PATCH, tallentaa ympäristöjä myöhempää käyttöä varten ja muuntaa API-liittymiä koodiksi useilla eri kielillä.
Jokainen API-syklin vaihe on yksinkertaistettu Postmanin avulla, ja yhteistyötä virtaviivaistetaan API-kehityksen nopeuttamiseksi.
Lisäksi sen avulla kehittäjät voivat hallita dokumentaatiota, spesifikaatioita, testitapauksia, prosesseja ja API-luetteloita.
26. Miten REST API:t pidetään turvassa?
Koska REST-sovellusliittymät eivät käytä yhtä tiukkoja suojatoimia kuin SOAP-sovellusliittymät, arkaluonteisia tietoja ei tule lähettää tai hakea niiden avulla.
Luotettavat REST-sovellusliittymät integroivat kuitenkin edelleen suojausohjauksia turvallisen ja luotettavan tiedonsiirron takaamiseksi.
- Todennus ja valtuutus: Jokaisen API:lle lähetetyn pyynnön on läpäistävä nämä kaksi tarkistusta. Asiakkaan henkilöllisyyden varmistaminen todennuksen avulla ja sen vahvistaminen, että heillä on valtuudet käyttää pyydettyjä resursseja valtuutuksen kautta, ovat kaksi eri prosessia.
- Validointi: Ennen kuin API myöntää pääsyn resursseihinsa, pyynnöt on silti tarkistettava todennuksen ja valtuutuksen jälkeen mahdollisen haitallisen koodin varalta. Palvelin olisi siten avoin injektiohyökkäykselle.
- Validointi: Ennen kuin API myöntää pääsyn resursseihinsa, pyynnöt on silti tarkistettava todennuksen ja valtuutuksen jälkeen mahdollisen haitallisen koodin varalta. Palvelin olisi siten avoin injektiohyökkäykselle.
- Salaus: TLS/SSL-salaus suojaa asiakkaan ja palvelimen välistä yhteyttä ja estää hakkereita sieppaamasta pyyntöjä ja vastauksia.
- Nopeutta rajoittavat tekniikat, kuten rajoitukset ja kuristus, suojaavat palvelimia raa'alta voimalta, kuten DDoS:lta, joiden tarkoituksena on heikentää tai kaataa niitä.
- Ei arkaluonteisia tietoja URI:issa: Resurssien URI:t eivät saa sisältää suojattuja tietoja (kuten käyttäjänimeä, salasanaa tai todennustunnusta).
Yhteenveto
Onnittelut! Useat perus- ja monimutkaiset REST API -haastattelukysymykset ja niihin liittyvät ratkaisut ovat nyt käden ulottuvilla.
Nyt kun sinulla on hyvä käsitys siitä, kuinka vastata joihinkin tyypillisiin REST API -haastattelukysymyksiin, voit jatkaa vastaamista haastatteluihin. Seuraava vaihe riippuu tavoitteistasi.
Vierailla Haastattelusarja Hashdorkin kanssa valmistautuakseen haastatteluihin.
Jätä vastaus