INHOUDSOPGAWE[Versteek][Wys]
- 1. Wat verstaan jy onder RUS?
- 2. Wat bedoel jy met REST API?
- 3. Wat presies is URI?
- 4. Wat is die kenmerke van RESTful Web Services?
- 5. Wat is die riglyne van RUS?
- 6. Noem die HTTP-metodes wat REST ondersteun.
- 7. Beskryf die beperkings wat deur 'n konsekwente koppelvlak geplaas word.
- 8. Wat presies is 'n RUS-hulpbron?
- 9. Wat beteken JAX-RS vir jou?
- 10. Wat onderskei AJAX en REST van mekaar?
- 11. Kan jy 'n paar RUSTIGE webdienste-nadele lys?
- 12. Wat onderskei PUT en POST tegnieke van mekaar?
- 13. Hoe toets jy RUSvolle webdienste?
- 14. Beskryf 'n REST API in die regte wêreld.
- 15. Hoe werk mikrodiensargitektuur?
- 16. Wat presies is caching?
- 17. Beskryf loonvrag.
- 18. Onderskei SEEP vs RUS?
- 19. Kan die vervoerlaagsekuriteitsprotokol (TLS) saam met REST gebruik word?
- 20. Idempotente metodes: wat is dit? Hoe is dit van toepassing op die wêreld van RUSTIGE webdienste?
- 21. Wat is die funksionaliteit van HTTP Basiese Verifikasie?
- 22. Dink jy GraphQL is die beste keuse om mikrodiensargitektuur te skep?
- 23. Wat is die belangrikste onderskeid tussen die veilige en idempotente HTTP-metodes?
- 24. Wat impliseer die JAX-RS API deur RESTful Root Resource Classes?
- 25. Wat presies is Postman, en hoekom word dit gebruik?
- 26. Hoe word REST API's veilig gehou?
- Gevolgtrekking
REST se evolusie het API's ongelooflik toeganklik gemaak, terwyl dit ook hul volle krag en potensiaal openbaar. REST API's is maklik om te skep en te kas as gevolg van hul hulpbron-georiënteerde argitektuur.
Verder was RESTful API's deurentyd die voorlopers van ander beduidende ontwikkelings soos wolkrekenaars en mikrodiens-gebaseerde ontwerp.
Daarom behoort dit geen verrassing te wees dat REST API-ontwikkelaars vandag in aanvraag is nie, gegewe hoe hulle besighede wat RESTful-dienste gebruik 'n mededingende voordeel bied. REST API's is 'n gewilde ontwerpneiging.
Baie IT-firmas wil REST API kennis van sagteware ontwikkelaars en vra daaroor in tegniese onderhoude.
Hier is 'n paar van die mees tipiese REST API-onderhoudvrae wat jou sal help om gereed te wees vir onderhoude by verskeie firmas as jy in die REST API-ontwikkelingsveld wil werk.
1. Wat verstaan jy onder RUS?
REST is 'n argitektoniese paradigma vir die ontwerp van webgebaseerde toepassings wat gebaseer is op die Hypertext Transfer Protocol (HTTP).
REST definieer sekere standaarde waaraan webdienste moet voldoen om as RUSTIG geag te word. Hierdie aanbevelings waarborg dat versoeke en hulpbronne vinnig en doeltreffend tussen kliënt en bediener oorgedra word deur gebruik te maak van gestandaardiseerde HTTP-protokolle.
2. Wat bedoel jy met REST API?
'n Sagteware-na-sagteware-skakel bekend as 'n toepassingsprogrammeringskoppelvlak maak kommunikasie en datadeling tussen andersins onafhanklike programme moontlik. Byvoorbeeld, 'n nuuswebwerf kan die Twitter API gebruik om pertinente twiets outomaties te ontdek en dit in nuusberigte te integreer.
'n API wat aan REST-beginsels voldoen, staan bekend as 'n REST API, soms bekend as 'n RESTful API. In 'n REST API word elke stuk data as 'n hulpbron hanteer en 'n duidelike standaardhulpbronidentiteit (URI) gegee.
Byvoorbeeld, die Twitter API maak elke tweet 'n herwinbare hulpbron wat vir kliënte beskikbaar is. Die Twitter API kan deur gebruikers gebruik word om tweets te plaas en ander webwerftake uit te voer.
3. Wat presies is URI?
A rekenaar netwerk na hulpbron verwys kan word deur 'n URI of eenvormige hulpbronidentifiseerder te gebruik. Dit dien as 'n middel om een hulpbron van 'n ander te skei. Die bronne is dalk aanlyn of nie.
As gevolg van hul standaardstruktuur maak URI's dit maklik om aan selfs verskeie soorte hulpbronne te koppel. Die ligging of naam van die hulpbron is ingesluit in URI's saam met 'n string karakters.
Die URI bestaan uit 'n pad, skema, navraag en ander elemente, maar sluit nie die protokol in nie.
Deur 'n protokol te gebruik, word URL's (Uniform Resource Locators) gebruik om hulpbronne op die internet of toeganklik daardeur te vind.
4. Wat is die kenmerke van RESTful Web Services?
- Die kliënt-bediener-paradigma is die grondslag van die diens.
- Die diens kan toegang verkry tot hulpbronne deur URI's te gebruik.
- Die diens gebruik die HTTP-protokol om data/hulpbronne te bekom, navrae uit te voer en ander take uit te voer.
- Boodskappe is die naam van die metode wat gebruik word om tussen die kliënt en die bediener te kommunikeer.
- Hierdie dienste kan ook die REST-argitektoniese patroon implementeer deur SOAP-dienste te gebruik.
- Om bedieneroproepe vir dieselfde soort herhalende versoeke te verminder, gebruik hierdie dienste ook die idee van cache.
5. Wat is die riglyne van RUS?
REST API's moet aan vyf kriteria voldoen:
Kliënt-bediener ontkoppeling: Slegs 'n reeks versoeke en antwoorde kan gebruik word om tussen die kliënt en bediener te kommunikeer. Slegs kliënte en bedieners kan onderskeidelik versoeke en antwoorde stuur. Hierdie eenvoudige idee stel beide partye in staat om onafhanklik van mekaar te funksioneer.
Eenvormige koppelvlak: Daar moet 'n eenvormige protokol vir alle kliënt-bedienerverbindings wees. Hierdie protokol vir REST is HTTP. Omdat elke toepassing data met dieselfde taal versoek en stuur, maak 'n konsekwente koppelvlak integrasies eenvoudiger.
Staatloos: Die bediener stoor geen rekords van vorige versoeke of antwoorde in staatlose kommunikasie nie. Elke versoek en antwoord verskaf al die besonderhede wat nodig is om die uitruiling te voltooi. Staatlose kommunikasie verhoog spoed, bespaar geheue en verminder die spanning op die bediener. Boonop vermy dit die potensiaal dat 'n versoek misluk as gevolg van onvolledige data.
Gelaagde stelsel: Bedieners wat tussen die kliënt en die API-bediener woon, word lae genoem. Hierdie ekstra bedieners voer 'n verskeidenheid dienste uit, soos om strooipos op te spoor en spoed te optimaliseer. Lae in REST is modulêr, wat beteken dat hulle bygevoeg en uitgevee kan word sonder om kommunikasie tussen die kliënt en die API-bediener te beïnvloed.
Kasbaar: Kliënte kan enige hulpbronne kas om spoed te verhoog as bedienerantwoorde aandui of die hulpbron kasbaar is of nie.
Op-aanvraag-kodering: In reaksie kan 'n API uitvoerbare rekenaarkode aan kliënte oordra. Die kliënttoepassing kan dan die kode op sy eie agterkant laat loop.
6. Noem die HTTP-metodes wat REST ondersteun.
Die HTTP-metodes wat REST ondersteun is:
- KRY: Hierdie metode vra vir 'n hulpbron by die gespesifiseerde URL. 'n Versoekliggaam moet nie ingesluit word nie, want dit sal geïgnoreer word. Dit kan moontlik wees om dit plaaslik of op die bediener te kas.
- POST: Hierdie metode stuur data na 'n diens vir verwerking, en die diens moet normaalweg 'n nuwe of veranderde hulpbron terugstuur.
- PUT: Die hulpbron word by die versoek-URL opgedateer.
- SKEE: Die hulpbron word by die versoek-URL uitgevee.
- Opsies: Dit identifiseer die ondersteunde metodes.
- HOOF: Die versoek-URL se metadata word teruggestuur.
7. Beskryf die beperkings wat deur 'n konsekwente koppelvlak geplaas word.
Om die kliënt van die bediener te skei, is 'n konsekwente koppelvlak nodig.
Om 'n konsekwente koppelvlak te bereik, word die volgende vier beperkings vereis:
- Hulpbronidentifikasie: Kliëntversoeke moet standaardhulpbron-ID's gebruik om hulpbronne (URI's) te identifiseer
- Hulpbronmanipulasie deur hierdie voorstellings te gebruik: Kliënte het al die inligting wat nodig is om hulpbronstatus te kan verander wanneer hulle 'n hulpbronvoorstelling van die bediener af kry.
- Selfbeskrywende boodskappe: Boodskappe sluit alle metadata en ander inligting in wat nodig is vir die ontvanger om dit te verstaan.
- Hipermedia as die toepassingstoestandenjin: Die kanaal vir kliënt-bediener-kommunikasie is hipermedia, soos HTML, en kliënte het nie API-spesifieke dokumentasie nodig om bedienerantwoorde te begryp nie.
8. Wat presies is 'n RUS-hulpbron?
Hulpbronne is die fundamentele komponente van 'n RESTful webdiens in 'n REST-argitektuur. Dit sluit alle belangrike inligting in waartoe 'n API-kliënt toegang moet verkry.
Enige tipe hulpbronne, soos 'n HTML-bladsy, 'n prent, 'n video of enigiets anders wat nodig is vir 'n API-aktiwiteit, kan verkry word deur die bediener in 'n kliënt-bedienerstelsel.
Die hulpbronne word geïdentifiseer deur 'n Uniform Resource Identifier. Teks, JSON of XML is almal aanvaarbare voorstellings van hulpbronne. Nadat dit gesê is, is daar geen beperkings op die voorstelling se formaat nie.
9. Wat beteken JAX-RS vir jou?
Dit is makliker om RESTful webdienste in Java te skep danksy die Java API vir RESTful webdienste, dikwels bekend as JAX-RS. Ontwikkelaars kan hulpbronne beskryf en die bewerkings wat daarop uitgevoer kan word met behulp van die aantekeninge wat verskaf word.
10. Wat onderskei AJAX en REST van mekaar?
Ajax:
- Ajax is 'n groep tegnologieë wat dit moontlik maak vir die dinamiese opdatering van gebruikerskoppelvlak elemente sonder om die bladsy te herlaai.
- Ajax verwyder asynchrone kommunikasie tussen die kliënt en bediener.
RUS:
- RUS vereis kommunikasie tussen die bediener en die kliënt.
- Die benutting van hulpbronne is belangrik vir die URL-struktuur en versoek/antwoordpatroon wat deur REST gebruik word.
11. Kan jy 'n paar RUSTIGE webdienste-nadele lys?
Sessies kan nie volgehou word nie aangesien die dienste aan die idee van staatloosheid voldoen. (Die kliënt is verantwoordelik om die sessie-ID deur die simulasie van die sessie deur te gee.)
Sekuriteitsbeperkings is nie fundamenteel vir REST nie. Die protokolle wat dit gebruik, erf die veiligheidsmaatreëls. Daarom is dit belangrik om versigtig te wees terwyl u sekuriteitsmaatreëls in plek stel, soos die integrasie van SSL/TLS-gebaseerde stawings.
12. Wat onderskei PUT en POST tegnieke van mekaar?
PUT:
- Daar is geen kas vir PUT-antwoorde nie.
- Idempotent (dws veelvuldige versoeke sal dieselfde resultaat lewer)
- die versoek se loonvrag dateer of vervang die teikenhulpbron.
POST:
- idempotent nie (dws veelvuldige versoeke sal veelvoude van dieselfde hulpbron oplewer)
- Die webbediener verwerk die loonvrag van die versoek gebaseer op die beoogde hulpbron.
- As die toepaslike kasbeheerkopskrif ingesluit is, kan POST-antwoorde gekas word.
13. Hoe toets jy RUSvolle webdienste?
RUSTIGE webdienstoetsing kan aangehelp word deur 'n aantal instrumente, insluitend Swagger en Postman. Die inspeksie van versoekparameters soos navraagparameters, opskrifte en antwoordopskrifte word moontlik gemaak deur laasgenoemde se oorvloed kenmerke.
Postman kan gebruik word om versoeke na eindpunte te rig en die resultate te wys. En XML en JSON kan uit hierdie antwoorde geskep word.
Postman en Swagger bied albei uiters vergelykbare funksies. Aan die ander kant bied Swagger ook vermoëns soos eindpuntdokumentasie.
14. Beskryf 'n REST API in die regte wêreld.
- Reis- en kaartjiewebwerwe kan die vlugtydsberekeninge en pryse wat lugrederye deur API's beskikbaar stel, benut.
- Ten einde kaart- en navigasieprogramme (soos Google Maps) dit te gebruik, maak openbare vervoeragentskappe hul data dikwels intyds publiek beskikbaar via API's.
- Weertoepassings gebruik oop API's wat weerdata uitruil om weerinligting te vertoon.
- Ontwikkelaars kan toegang verkry tot Google Maps se karteringdata via 'n aantal van sy gasheer-API's. Hierdie API's word deur ontwikkelaars gebruik om dinamiese kaarte in hul toepassings en webwerwe in te sluit.
15. Hoe werk mikrodiensargitektuur?
- Versoeke word gestuur deur verskeie kliënte met behulp van verskeie toestelle.
- Nadat die kliënte se identiteite bevestig is, verskaf identiteitsverskaffers sekuriteitsbewyse.
- Die kliëntversoeke word deur API Gateway bestuur.
- Al die stelsel se materiaal word as statiese inhoud bewaar.
- Die bestuursinstrument kontroleer die balans van dienste op nodusse en enige foute.
- Die ontdekking van die pad van kommunikasie tussen mikrodienste word aangehelp deur diensontdekking.
- Datasentrums en instaanbedieners vorm verspreide netwerkstelsels wat inhoudafleweringsnetwerke genoem word.
- Afgeleë dienste verskaf toegang tot inligting vanaf 'n afstand.
16. Wat presies is caching?
Die praktyk om tydelik 'n kopie van 'n bedienerantwoord iewers (soos rekenaargeheue) te hou om dit later vinniger te bekom, staan bekend as caching.
Cache verhoog bedienerspoed wanneer REST API's gebruik word deur die hoeveelheid werk wat die bediener moet doen om aan die versoek te voldoen, te verminder. Toepassings wat die API gebruik, loop vinniger danksy kas, want hulle hoef nie 'n nuwe versoek in te dien elke keer as hulle 'n hulpbron benodig nie.
Die HTTP-reaksie-opskrif se Cache-Control-veld bevat inligting oor hoe lank 'n hulpbron deur die kliënt gekas kan word voordat dit weer toegang moet kry.
17. Beskryf loonvrag.
Die loonvrag in REST verwys na die inligting vervat in die liggaam van die HTTP-antwoord. Die kliënt het die AOO-tegniek gebruik om die betrokke data aan te vra.
Die dokument wat die tweet-teks en enige nodige lêers bevat om die tweet op 'n webwerf te plaas, sal byvoorbeeld by die loonvrag ingesluit word as jy die Twitter API vir 'n spesifieke twiet vra. Boonop kan die loonvrag by die HTTP-versoek ingesluit word deur die POST-metode te gebruik.
18. Onderskei SEEP Vs RUS?
- Anders as SOAP, wat slegs XML kan hanteer, maak REST 'n groter verskeidenheid hulpbronformate moontlik, insluitend XML, teks, HTML, prente, video, en meer.
- Wanneer sekuriteit noodsaaklik is vir aanlyntoepassings, is SOAP nuttig. REST kan nie gebruik word wanneer transaksies veilig voltooi moet word nie, aangesien dit nie besonder veilig is nie.
- Aangesien SOAP slegs 'n protokol is, kan REST dit in sy webdienste gebruik, maar nie andersom nie.
- Terwyl REST slegs 'n argitektoniese patroon is wat gebruik word om webdienste te ontwikkel en voldoen aan sekere beperkings soos kliënt-bediener-opstelling, staatloosheid, kas-reaksie, gelaagde stelsels en konsekwente koppelvlak, is SOAP 'n protokol wat werk op spesifieke standaarde wat streng nagekom moet word aan.
- Terwyl REST universele hulpbronidentifiseerders (URI's) gebruik, gebruik SOAP dienskoppelvlakke om sy vermoëns aan kliënttoepassings te verskaf. REST het 'n laer bandwydte behoefte as SOAP aangesien SOAP boodskappe meer inligting-swaar is.
19. Kan die vervoerlaagsekuriteitsprotokol (TLS) saam met REST gebruik word?
Trouens, ons kan. Die REST-kliënt en bediener se kommunikasie word via TLS geïnkripteer, en die protokol gee kliënte ook 'n manier om bedieners te verifieer.
As gevolg van die feit dat dit die Secure Socket Layer se plaasvervanger is, word dit vir veilige kommunikasie (SSL) gebruik. Die implementering van RESTful-webdienste is suksesvol met HTTPS omdat dit effektief met beide TLS en SSL saamwerk.
Die REST erf die kenmerke van die protokol wat dit implementeer, wat een ding is om hier op te let. Gevolglik is sekuriteitsbeskerming afhanklik van die protokol wat REST gebruik.
20. Idempotente metodes: wat is dit? Hoe is dit van toepassing op die wêreld van RUSTIGE webdienste?
Wanneer die URI dieselfde is, het sommige HTTP-metodes in 'n versoek dieselfde impak op die bediener of hulle een of meer keer afgelewer word. Idempotente tegnieke is wat dit bekend staan as.
Byvoorbeeld, maak nie saak hoeveel keer 'n URI met die GET-metode uitgevoer word nie, die bediener sal altyd dieselfde resultaat ervaar. Idempotente metodes sluit in GET, PUT en PATCH, om 'n paar te noem.
Idempotente HTTP-metodes is sommige van die wat deur RESTful gebruik word webtoepassings. Hulle is nodig om konsekwentheid in die RESTful webdienste se aktiwiteite te waarborg.
Kliënte wat REST API's gebruik, kan kodefoute maak wat 'n REST API dwing om per ongeluk herhaalde versoeke te maak. Hierdie oproepe het die potensiaal om hulpbronne te misbruik.
21. Wat is die funksionaliteit van HTTP Basiese Verifikasie?
Wanneer Basiese Verifikasie as deel van API's gebruik word, moet die gebruiker die gebruikersnaam en wagwoord indien, wat deur die blaaier aaneengeskakel word in die vorm "gebruikersnaam: wagwoord" en base64 geënkodeer.
Op elke HTTP-versoek van die blaaier word die geënkodeerde waarde as die waarde vir die "Magtiging"-opskrif gelewer. Omdat die geloofsbriewe net geënkodeer is, word dit aanbeveel om hierdie vorm te gebruik wanneer HTTPS-versoeke gestuur word omdat dit nie veilig is nie en deur enigiemand onderskep kan word as sekuriteitsprotokolle nie gebruik word nie.
22. Dink jy GraphQL is die beste keuse om mikrodiensargitektuur te skep?
Mikrodienste en GraphQL pas perfek saam, want GraphQL hou u mikrodiensargitektuur geheim vir u kliënte.
Van die voorkant af wil jy hê dat al jou data van 'n enkele API moet kom, terwyl jy dit van die agterkant in mikrodienste wil verdeel. Die beste tegniek waarvan ek bewus is om albei te bereik, is deur GraphQL te gebruik.
Dit stel jou in staat om jou agterkant in mikrodienste te verdeel terwyl jy steeds elke toepassing 'n enkele API gee en aansluitings oor data van verskeie dienste moontlik maak.
23. Wat is die belangrikste onderskeid tussen die veilige en idempotente HTTP-metodes?
Idempotente metodes lewer dieselfde resultaat wanneer dit een of verskeie kere deur dieselfde versoek opgeroep word. Die PUT-metode is idempotent.
Alle veilige maniere is idempotent, maar nie alle idempotente metodes is veilig nie aangesien veilige metodes nie die hulpbronne verander nie. GET is byvoorbeeld veilig aangesien dit net data ophaal en nie die hulpbron verander nie.
Daarbenewens is dit idempotent, wat beteken dat dit altyd dieselfde antwoord sal gee wanneer dit opgeroep word.
24. Wat impliseer die JAX-RS API deur RESTful Root Resource Classes?
Die Java Enterprise Edition bied klasse en koppelvlakke wat voldoen aan die JAX-RS API vereistes. Met behulp van JAX-RS word die skep van Java-webdienste in die REST-argitektoniese styl makliker gemaak.
In die JAX-RS API is wortelhulpbronklasse net "gewone ou java-voorwerpe," of POJO. Om die nodige webhulpbronne te implementeer, gebruik hulle JAX-RS-aantekeninge.
Hulle het óf @pad-aantekeninge óf ten minste een van hul metodes het @pad-aantekeninge. Hulle kan opgesom word as Java-klasse met metodes om API-eindpunte te hanteer.
25. Wat presies is Postman, en hoekom word dit gebruik?
'n API-ontwikkelingsinstrument genaamd Postman word gebruik om API's te skep, te toets en te wysig. Hierdie instrument kan deur ontwikkelaars gebruik word vir watter kenmerk hulle ook al vir 'n API benodig. Dit vereenvoudig en vergemaklik ontwikkelaars se werk.
Postman maak dit maklik om 'n verskeidenheid HTTP-navrae te maak, insluitend GET, POST, PUT en PATCH, omgewings te stoor vir latere gebruik, en API's om te skakel na kode in 'n aantal verskillende tale.
Elke stadium van die API-siklus word met Postman eenvoudiger gemaak, en samewerking word vaartbelyn gemaak vir vinniger API-ontwikkeling.
Boonop stel dit ontwikkelaars in staat om die dokumentasie, spesifikasies, toetsgevalle, prosesse en API-katalogusse te bestuur.
26. Hoe word REST API's veilig gehou?
Aangesien REST API's nie so streng sekuriteitsvoorsorgmaatreëls soos SOAP API's gebruik nie, moet sensitiewe data nie deur hulle gestuur of herwin word nie.
Betroubare REST API's integreer egter sekuriteitskontroles vir veilige en betroubare data-oordragte.
- Stawing en magtiging: Elke versoek wat aan die API gemaak word, moet hierdie twee kontroles slaag. Om die kliënt se identiteit deur verifikasie te verifieer en te bevestig dat hulle magtiging het om toegang tot die gevraagde hulpbronne deur middel van magtiging te verkry, is twee verskillende prosesse.
- Bekragtiging: Voordat die API toegang tot sy hulpbronne verleen, moet versoeke steeds na verifikasie en magtiging nagegaan word vir moontlike skadelike kode. 'n Bediener sal dus oop wees vir 'n inspuitingsaanval.
- Bekragtiging: Voordat die API toegang tot sy hulpbronne verleen, moet versoeke steeds na verifikasie en magtiging nagegaan word vir moontlike skadelike kode. 'n Bediener sal dus oop wees vir 'n inspuitingsaanval.
- Enkripsie: TLS/SSL-enkripsie beskerm die verbinding tussen die kliënt en bediener en keer dat hackers versoeke en antwoorde onderskep.
- Tempo-beperkende tegnieke, soos limiete en versnelling, beskerm bedieners teen brute-krag-aanvalle soos DDoS wat daarop gemik is om hulle te verneder of te verongeluk.
- Geen sensitiewe inligting in URI's nie: Hulpbronne se URI's behoort geen beskermde data (soos 'n gebruikernaam, wagwoord of stawingtoken) te bevat nie.
Gevolgtrekking
Baie geluk! Verskeie basiese tot komplekse REST API-onderhoudvrae en hul onderskeie oplossings is nou binne jou vingers.
Noudat jy 'n goeie konsep het van hoe om op sommige van die tipiese REST API-onderhoudvrae te reageer, kan jy voortgaan om op die onderhoude te reageer. Die volgende stap hang af van jou doelwitte.
Besoek Onderhoudreeks met Hashdork om voor te berei vir onderhoude.
Lewer Kommentaar