Բառը[Թաքցնել][Ցուցադրում]
- 1. Ի՞նչ եք հասկանում ՀԱՆԳՍՏԵԼ:
- 2. Ի՞նչ նկատի ունեք REST API ասելով:
- 3. Ի՞նչ է կոնկրետ URI-ն:
- 4. Որո՞նք են RESTful Web Services-ի առանձնահատկությունները:
- 5. Որո՞նք են REST-ի առաջնորդող սկզբունքները:
- 6. Նշեք HTTP մեթոդները, որոնք աջակցում է REST-ը:
- 7. Նկարագրեք հետևողական ինտերֆեյսի կողմից դրված սահմանափակումները:
- 8. Ի՞նչ է իրենից ներկայացնում REST ռեսուրսը:
- 9. Ի՞նչ է ձեզ համար նշանակում JAX-RS:
- 10. Ինչո՞վ է տարբերվում AJAX-ը և REST-ը միմյանցից:
- 11. Կարո՞ղ եք թվարկել RESTful վեբ ծառայությունների թերությունները:
- 12. Ինչո՞վ է տարբերվում PUT և POST տեխնիկաները միմյանցից:
- 13. Ինչպե՞ս եք փորձարկում RESTful վեբ ծառայությունները:
- 14. Նկարագրեք REST API-ն իրական աշխարհում:
- 15. Ինչպե՞ս է աշխատում Microservice Architecture-ը:
- 16. Ի՞նչ է կոնկրետ քեշավորումը:
- 17. Նկարագրեք օգտակար բեռը:
- 18. Տարբերե՞լ Օճառը Հանգիստից:
- 19. Կարո՞ղ է արդյոք տրանսպորտային շերտի անվտանգության արձանագրությունը (TLS) օգտագործվել REST-ի հետ:
- 20. Իդեմպոտենտ մեթոդներ. որո՞նք են դրանք: Ինչպե՞ս է դա վերաբերում RESTful վեբ ծառայությունների աշխարհին:
- 21. Ո՞րն է HTTP Հիմնական նույնականացման գործառույթը:
- 22. Ի՞նչ եք կարծում, GraphQL-ը լավագույն ընտրությունն է միկրոսերվիսային ճարտարապետություն ստեղծելու համար:
- 23. Որո՞նք են հիմնական տարբերությունները անվտանգ և անգործունակ HTTP մեթոդների միջև:
- 24. Ի՞նչ է ենթադրում JAX-RS API-ն RESTful Root Resource Classes-ի կողմից:
- 25. Ի՞նչ է կոնկրետ փոստատարը և ինչու է այն օգտագործվում:
- 26. Ինչպե՞ս են REST API-ները ապահով պահվում:
- Եզրափակում
REST-ի էվոլյուցիան API-ներին անհավանական հասանելի է դարձրել՝ միաժամանակ բացահայտելով դրանց ողջ ուժն ու ներուժը: REST API-ները հեշտ է ստեղծել և քեշավորել՝ իրենց ռեսուրսների վրա հիմնված ճարտարապետության պատճառով:
Բացի այդ, ժամանակի ընթացքում RESTful API-ները եղել են այլ նշանակալի զարգացումների նախակարապետները, ինչպիսիք են ամպային հաշվարկը և միկրոծառայությունների վրա հիմնված դիզայնը:
Հետևաբար, չպետք է զարմանա, որ REST API մշակողները այսօր պահանջված են՝ հաշվի առնելով, թե ինչպես են նրանք մրցակցային առավելություններ տրամադրող բիզնեսներին, որոնք օգտագործում են RESTful ծառայություններ: REST API-ները դիզայնի հայտնի միտում են:
Շատ ՏՏ ընկերություններ ցանկանում են REST API-ի իմացություն ստանալ ծրագրավորողներ և դրա մասին հարցրեք տեխնիկական հարցազրույցներում:
Ահա մի քանի առավել բնորոշ REST API հարցազրույցի հարցեր, որոնք կօգնեն ձեզ պատրաստ լինել տարբեր ընկերություններում հարցազրույցների, եթե ցանկանում եք աշխատել REST API-ի մշակման ոլորտում:
1. Ի՞նչ եք հասկանում ՀԱՆԳՍՏԵԼ:
REST-ը ճարտարապետական պարադիգմ է՝ վեբ վրա հիմնված հավելվածների նախագծման համար, որոնք հիմնված են Hypertext Transfer Protocol-ի (HTTP) վրա:
REST-ը սահմանում է որոշակի ստանդարտներ, որոնց պետք է համապատասխանեն վեբ ծառայությունները, որպեսզի համարվեն ՀԱՆԳԻՍՏ: Այս առաջարկությունները երաշխավորում են, որ հարցումները և ռեսուրսները արագ և արդյունավետ կերպով փոխանցվում են հաճախորդի և սերվերի միջև՝ օգտագործելով ստանդարտացված HTTP արձանագրությունները:
2. Ի՞նչ նկատի ունեք REST API ասելով:
Ծրագրաշարից ծրագրակազմ կապը, որը հայտնի է որպես հավելվածի ծրագրավորման ինտերֆեյս, հնարավորություն է տալիս հաղորդակցության և տվյալների փոխանակման այլապես անկախ ծրագրերի միջև: Օրինակ, լրատվական կայքը կարող է օգտագործել Twitter API-ն՝ ինքնաբերաբար համապատասխան թվիթներ հայտնաբերելու և դրանք նորությունների մեջ ինտեգրելու համար:
API, որը հավատարիմ է REST սկզբունքներին, հայտնի է որպես REST API, երբեմն հայտնի է որպես RESTful API: REST API-ում տվյալների յուրաքանչյուր կտոր մշակվում է որպես ռեսուրս և տրվում է հստակ ստանդարտ ռեսուրսի ինքնություն (URI):
Օրինակ, Twitter API-ն յուրաքանչյուր թվիթը դարձնում է վերադարձելի ռեսուրս, որը հասանելի է հաճախորդների համար: Twitter API-ն կարող է օգտագործվել օգտատերերի կողմից թվիթներ տեղադրելու և կայքի այլ առաջադրանքներ կատարելու համար:
3. Ի՞նչ է կոնկրետ URI-ն:
A համակարգչային ցանց ռեսուրսը կարող է վերաբերվել URI-ի կամ միատեսակ ռեսուրսի նույնացուցիչի օգտագործմանը: Այն ծառայում է որպես մեկ ռեսուրս մյուսից բաժանելու միջոց: Աղբյուրները կարող են լինել կամ չլինել առցանց:
Իրենց ստանդարտ կառուցվածքի շնորհիվ URI-ները հեշտացնում են նույնիսկ տարբեր տեսակի ռեսուրսների միացումը: Ռեսուրսի գտնվելու վայրը կամ անվանումը ներառված է URI-ներում նիշերի շարանով:
URI-ն կազմված է ուղուց, սխեմայից, հարցումից և այլ տարրերից, բայց չի ներառում արձանագրությունը:
Արձանագրության միջոցով URL-ները (Resource Locators) օգտագործվում են ինտերնետում ռեսուրսներ գտնելու կամ դրա միջոցով հասանելի ռեսուրսներ գտնելու համար:
4. Որո՞նք են RESTful Web Services-ի առանձնահատկությունները:
- Հաճախորդ-Սերվեր պարադիգմը ծառայության հիմքն է:
- Ծառայությունը կարող է մուտք գործել ռեսուրսներ URI-ների միջոցով:
- Ծառայությունն օգտագործում է HTTP արձանագրությունը՝ տվյալներ/ռեսուրսներ ձեռք բերելու, հարցումներ գործարկելու և այլ առաջադրանքներ կատարելու համար:
- Հաղորդագրություններն այն մեթոդի անվանումն է, որն օգտագործվում է հաճախորդի և սերվերի միջև հաղորդակցվելու համար:
- Այս ծառայությունները կարող են նաև իրականացնել REST ճարտարապետական օրինակը՝ օգտագործելով SOAP ծառայությունները:
- Նույն տեսակի կրկնվող հարցումների համար սերվերի զանգերը նվազեցնելու համար այս ծառայությունները նաև օգտագործում են քեշավորման գաղափարը:
5. Որո՞նք են REST-ի առաջնորդող սկզբունքները:
REST API-ները պետք է բավարարեն հինգ չափանիշներ.
Հաճախորդ-սերվեր անջատում. հաճախորդի և սերվերի միջև հաղորդակցվելու համար կարող են օգտագործվել միայն մի շարք հարցումներ և պատասխաններ: Միայն հաճախորդները և սերվերները կարող են համապատասխանաբար ուղարկել հարցումներ և պատասխաններ: Այս պարզ գաղափարը երկու կողմերին էլ հնարավորություն է տալիս աշխատել միմյանցից անկախ:
Միատեսակ ինտերֆեյս. հաճախորդ-սերվեր բոլոր կապերի համար պետք է լինի միասնական արձանագրություն: REST-ի այս արձանագրությունը HTTP է: Քանի որ յուրաքանչյուր հավելված պահանջում և ուղարկում է տվյալներ՝ օգտագործելով նույն լեզուն, հետևողական ինտերֆեյսը հեշտացնում է ինտեգրումները:
Քաղաքացիություն չունեցող. Սերվերը քաղաքացիություն չունեցող հաղորդակցության մեջ չի պահպանում նախորդ հարցումների կամ պատասխանների որևէ գրառում: Յուրաքանչյուր հարցում և պատասխան տրամադրում է բոլոր մանրամասները, որոնք անհրաժեշտ են փոխանակումն ավարտելու համար: Քաղաքացիություն չունեցող հաղորդակցությունը մեծացնում է արագությունը, խնայում է հիշողությունը և նվազեցնում է սերվերի սթրեսը: Բացի այդ, այն խուսափում է ոչ ամբողջական տվյալների պատճառով հարցումը ձախողելու հավանականությունից:
Շերտավոր համակարգ. Սերվերները, որոնք գտնվում են հաճախորդի և API սերվերի միջև, կոչվում են շերտեր: Այս լրացուցիչ սերվերները կատարում են մի շարք ծառայություններ, ինչպիսիք են սպամի հայտնաբերումը և արագության օպտիմալացումը: REST-ի շերտերը մոդուլային են, ինչը նշանակում է, որ դրանք կարող են ավելացվել և ջնջվել՝ առանց հաճախորդի և API սերվերի միջև հաղորդակցության վրա ազդելու:
Cacheable. Հաճախորդները կարող են քեշավորել ցանկացած ռեսուրս արագությունը բարձրացնելու համար, եթե սերվերի պատասխանները ցույց են տալիս, թե արդյոք ռեսուրսը քեշավորելի է, թե ոչ:
Ըստ պահանջի կոդավորում. Ի պատասխան՝ API-ն կարող է հաճախորդներին փոխանցել գործարկվող համակարգչային ծածկագիրը: Հաճախորդի հավելվածն այնուհետև կարող է գործարկել կոդը իր հետևի վրա:
6. Նշեք HTTP մեթոդները, որոնք աջակցում է REST-ը:
HTTP մեթոդները, որոնք աջակցում է REST-ը, հետևյալն են.
- GET. Այս մեթոդը պահանջում է ռեսուրս նշված URL-ում: Հարցման մարմինը չպետք է ներառվի, քանի որ այն անտեսվելու է: Հնարավոր է այն քեշավորել տեղական կամ սերվերի վրա:
- POST. Այս մեթոդը տվյալներ է ուղարկում ծառայության մշակման համար, և ծառայությունը սովորաբար պետք է վերադարձնի նոր կամ փոփոխված ռեսուրս:
- PUT. ռեսուրսը թարմացվում է հարցման URL-ով:
- Ջնջել. ռեսուրսը ջնջվում է հարցման URL-ով:
- Ընտրանքներ. այն նույնացնում է աջակցվող մեթոդները:
- HEAD. Հարցման URL-ի մետատվյալները վերադարձվում են:
7. Նկարագրեք հետևողական ինտերֆեյսի կողմից դրված սահմանափակումները:
Հաճախորդին սերվերից բաժանելու համար անհրաժեշտ է հետևողական ինտերֆեյս:
Հետևողական ինտերֆեյսի հասնելու համար պահանջվում են հետևյալ չորս սահմանափակումները.
- Ռեսուրսների նույնականացում. Հաճախորդի հարցումները պետք է օգտագործեն ռեսուրսների ստանդարտ ID-ներ՝ ռեսուրսները (URI-ներ) նույնականացնելու համար:
- Ռեսուրսների մանիպուլյացիա՝ օգտագործելով այս ներկայացումները. հաճախորդներն ունեն բոլոր անհրաժեշտ տեղեկությունները, որպեսզի կարողանան փոխել ռեսուրսի վիճակը, երբ նրանք ստանում են ռեսուրսի ներկայացում սերվերից:
- Ինքն նկարագրող հաղորդագրություններ. Հաղորդագրությունները ներառում են բոլոր մետատվյալները և այլ տեղեկությունները, որոնք պահանջվում են ստացողի կողմից դրանք հասկանալու համար:
- Հիպերմեդիան որպես հավելվածի վիճակի շարժիչ. Հաճախորդ-սերվեր հաղորդակցության ալիքը հիպերմեդիա է, ինչպիսին է HTML-ը, և հաճախորդները API-ին հատուկ փաստաթղթերի կարիք չունեն սերվերի պատասխանները հասկանալու համար:
8. Ի՞նչ է իրենից ներկայացնում REST ռեսուրսը:
Ռեսուրսները RESTful վեբ ծառայության հիմնական բաղադրիչներն են REST ճարտարապետության մեջ: Դրանք ներառում են բոլոր կարևոր տեղեկությունները, որոնք պետք է հասանելի լինեն API-ի հաճախորդին:
Ցանկացած տեսակի ռեսուրսներ, ինչպիսիք են HTML էջը, պատկերը, տեսանյութը կամ որևէ այլ բան, որն անհրաժեշտ է API-ի գործունեության համար, կարելի է մուտք գործել սերվերի միջոցով հաճախորդ-սերվեր համակարգում:
Ռեսուրսները նույնականացվում են Uniform Resource Identifier-ով: Տեքստը, JSON-ը կամ XML-ը ռեսուրսների ընդունելի ներկայացումներ են: Այսպես ասելով, ներկայացուցչության ձևաչափի հետ կապված սահմանափակումներ չկան:
9. Ի՞նչ է ձեզ համար նշանակում JAX-RS:
Ավելի պարզ է Java-ում RESTful վեբ ծառայություններ ստեղծելը RESTful վեբ ծառայությունների Java API-ի շնորհիվ, որը հաճախ հայտնի է որպես JAX-RS: Մշակողները կարող են նկարագրել ռեսուրսները և այն գործողությունները, որոնք կարող են իրականացվել դրանց վրա՝ օգտագործելով տրամադրված ծանոթագրությունները:
10. Ինչո՞վ է տարբերվում AJAX-ը և REST-ը միմյանցից:
Այաքս:
- Ajax-ը տեխնոլոգիաների խումբ է, որը թույլ է տալիս դինամիկ թարմացնել օգտագործողի ինտերֆեյս տարրեր՝ առանց էջը վերաբեռնելու:
- Ajax-ը հեռացնում է հաճախորդի և սերվերի միջև ասինխրոն հաղորդակցությունը:
ՀԱՆԳՍՏՈՒՄ:
- REST-ը պահանջում է կապ սերվերի և հաճախորդի միջև:
- Ռեսուրսների օգտագործումը կարևոր է REST-ի կողմից օգտագործվող URL-ի կառուցվածքի և հարցում/պատասխանի ձևի համար:
11. Կարո՞ղ եք թվարկել RESTful վեբ ծառայությունների թերությունները:
Նիստերը չեն կարող շարունակվել, քանի որ ծառայությունները հավատարիմ են քաղաքացիություն չունեցող հասկացությանը: (Հաճախորդը պատասխանատու է նիստի id-ի փոխանցման համար սեսիայի սիմուլյացիայի ողջ ընթացքում):
Անվտանգության սահմանափակումները հիմնարար նշանակություն չունեն REST-ի համար: Արձանագրությունները, որոնք օգտագործում են այն, ժառանգում են անվտանգության նախազգուշական միջոցները: Հետևաբար, կարևոր է զգույշ լինել անվտանգության միջոցների ներդրման ժամանակ, ինչպիսիք են SSL/TLS-ի վրա հիմնված նույնականացումների ինտեգրումը:
12. Ինչո՞վ է տարբերվում PUT և POST տեխնիկաները միմյանցից:
ԴՆԵԼ:
- PUT պատասխանների համար քեշ չկա:
- Idempotent (այսինքն մի քանի հարցումները կտան նույն արդյունքը)
- հարցումի օգտակար բեռը թարմացնում կամ փոխարինում է թիրախային ռեսուրսը:
POST:
- idempotent not (այսինքն, մի քանի հարցումները կբերեն նույն ռեսուրսի բազմապատիկները)
- Վեբ սերվերը մշակում է հարցումի ծանրաբեռնվածությունը՝ հիմնվելով նախատեսված ռեսուրսի վրա:
- Եթե համապատասխան քեշի վերահսկման վերնագիր ներառված է, POST-ի պատասխանները կարող են պահվել:
13. Ինչպե՞ս եք փորձարկում RESTful վեբ ծառայությունները:
RESTful վեբ ծառայության փորձարկմանը կարող են օգնել մի շարք գործիքներ, ներառյալ Swagger-ը և Postman-ը: Հարցման պարամետրերի ստուգումը, ինչպիսիք են հարցման պարամետրերը, վերնագրերը և պատասխանների վերնագրերը, հնարավոր է դառնում վերջինիս առատության շնորհիվ:
Postman-ը կարող է օգտագործվել վերջնական կետերին հարցումներ կատարելու և արդյունքները ցույց տալու համար: Եվ այս պատասխաններից կարելի է ստեղծել XML և JSON:
Postman-ը և Swagger-ը երկուսն էլ ապահովում են չափազանց համադրելի գործառույթներ: Մյուս կողմից, Swagger-ն առաջարկում է նաև հնարավորություններ, ինչպիսիք են վերջնական կետի փաստաթղթերը:
14. Նկարագրեք REST API-ն իրական աշխարհում:
- Ճանապարհորդության և տոմսերի վաճառքի կայքերը կարող են օգտագործել թռիչքների ժամանակացույցը և գները, որոնք ավիաընկերությունները հասանելի են դարձնում API-ների միջոցով:
- Որպեսզի քարտեզագրման և նավիգացիոն հավելվածները (օրինակ՝ Google Քարտեզները) օգտագործեն դրանք, հասարակական տրանսպորտի գործակալությունները հաճախ իրենց տվյալները հասանելի են դարձնում իրական ժամանակում API-ների միջոցով:
- Եղանակային հավելվածներն օգտագործում են բաց API-ներ, որոնք եղանակային տվյալներ են փոխանակում՝ եղանակի մասին տեղեկատվությունը ցուցադրելու համար:
- Մշակողները կարող են մուտք գործել Google Քարտեզների քարտեզագրման տվյալներ իր հյուրընկալված մի շարք API-ների միջոցով: Այս API-ներն օգտագործվում են մշակողների կողմից՝ իրենց հավելվածներում և կայքերում դինամիկ քարտեզներ տեղադրելու համար:
15. Ինչպե՞ս է աշխատում Microservice Architecture-ը:
- Հարցումները ուղարկվում են տարբեր հաճախորդների կողմից՝ օգտագործելով տարբեր սարքեր:
- Հաճախորդների ինքնությունը հաստատելուց հետո ինքնության մատակարարները տրամադրում են անվտանգության նշաններ:
- Հաճախորդի հարցումները կառավարվում են API Gateway-ի կողմից:
- Համակարգի ամբողջ նյութը պահպանվում է որպես ստատիկ բովանդակություն:
- Կառավարման գործիքը ստուգում է ծառայությունների հավասարակշռությունը հանգույցների և ցանկացած անսարքության վրա:
- Միկրոծառայությունների միջև հաղորդակցության ուղու բացահայտմանը նպաստում է ծառայության հայտնաբերումը:
- Տվյալների կենտրոնները և պրոքսի սերվերները կազմում են ցրված ցանցային համակարգեր, որոնք կոչվում են բովանդակության առաքման ցանցեր:
- Հեռավոր ծառայություններն ապահովում են տեղեկատվության հասանելիությունը հեռավորությունից:
16. Ի՞նչ է կոնկրետ քեշավորումը:
Սերվերի պատասխանի պատճենը ինչ-որ տեղ ժամանակավոր պահելու պրակտիկան (օրինակ՝ համակարգչի հիշողությունը), որպեսզի հետագայում ավելի արագ մուտք գործի դրան, հայտնի է որպես քեշավորում:
Քեշավորումը մեծացնում է սերվերի արագությունը REST API-ներ օգտագործելիս՝ նվազեցնելով աշխատանքի ծավալը, որը սերվերը պետք է կատարի հարցումը բավարարելու համար: Հավելվածները, որոնք օգտագործում են API-ն, ավելի արագ են աշխատում քեշավորման շնորհիվ, քանի որ նրանք կարիք չունեն նոր հարցում ներկայացնել ամեն անգամ, երբ ռեսուրսի կարիք ունեն:
HTTP պատասխանի վերնագրի «Cache-Control» դաշտը պարունակում է տեղեկատվություն այն մասին, թե որքան ժամանակ կարող է ռեսուրսը պահվել հաճախորդի կողմից, մինչև այն նորից մուտք գործի:
17. Նկարագրեք օգտակար բեռը:
REST-ում օգտակար բեռը վերաբերում է HTTP պատասխանի մարմնում պարունակվող տեղեկատվությանը: Հաճախորդը օգտագործել է GET տեխնիկան խնդրո առարկա տվյալներ ստանալու համար:
Թվիթի տեքստը պարունակող փաստաթուղթը և ցանկացած անհրաժեշտ ֆայլ՝ թվիթը վեբկայքում տեղադրելու համար, կներառվեն օգտակար բեռնվածության մեջ, օրինակ, եթե Twitter API-ից խնդրեք որոշակի թվիթ: Բացի այդ, ծանրաբեռնվածությունը կարող է ներառվել HTTP հարցման մեջ՝ օգտագործելով POST մեթոդը:
18. Տարբերակել Օճառ ընդդեմ ՀԱՆԳՍՏԻ?
- Ի տարբերություն SOAP-ի, որը կարող է աշխատել միայն XML-ով, REST-ը հնարավորություն է տալիս ռեսուրսների ձևաչափերի ավելի լայն շրջանակ, ներառյալ XML, տեքստ, HTML, նկարներ, տեսանյութեր և այլն:
- Երբ անվտանգությունը շատ կարևոր է առցանց հավելվածների համար, SOAP-ն օգտակար է: REST-ը չի կարող օգտագործվել, երբ գործարքները պետք է ապահով կատարվեն, քանի որ այն առանձնապես ապահով չէ:
- Քանի որ SOAP-ը միայն արձանագրություն է, REST-ը կարող է օգտագործել այն իր վեբ ծառայություններում, բայց ոչ հակառակը:
- Թեև REST-ը միայն ճարտարապետական օրինաչափություն է, որն օգտագործվում է վեբ ծառայությունների մշակման համար և ենթարկվում է որոշակի սահմանափակումների, ինչպիսիք են հաճախորդ-սերվերի կարգավորումը, քաղաքացիության բացակայությունը, քեշավոր պատասխանը, շերտավոր համակարգերը և հետևողական ինտերֆեյսը, SOAP-ը արձանագրություն է, որը գործում է որոշակի ստանդարտներով, որոնք պետք է խստորեն պահպանվեն: դեպի.
- Մինչ REST-ն օգտագործում է ունիվերսալ ռեսուրսների նույնացուցիչներ (URIs), SOAP-ն օգտագործում է սպասարկման միջերեսներ՝ հաճախորդների հավելվածներին իր հնարավորությունները տրամադրելու համար: REST-ն ունի ավելի ցածր թողունակության կարիք, քան SOAP-ը, քանի որ SOAP հաղորդագրություններն ավելի շատ տեղեկատվական են:
19. Կարո՞ղ է արդյոք տրանսպորտային շերտի անվտանգության արձանագրությունը (TLS) օգտագործվել REST-ի հետ:
Փաստորեն, մենք կարող ենք։ REST հաճախորդի և սերվերի հաղորդակցությունը գաղտնագրված է TLS-ի միջոցով, և արձանագրությունը նաև հաճախորդներին հնարավորություն է տալիս հաստատել սերվերները:
Քանի որ այն հանդիսանում է Secure Socket Layer-ի փոխարինող, այն օգտագործվում է անվտանգ հաղորդակցության համար (SSL): RESTful վեբ ծառայությունների ներդրումը հաջողված է HTTPS-ի հետ, քանի որ այն արդյունավետորեն համագործակցում է ինչպես TLS-ի, այնպես էլ SSL-ի հետ:
REST-ը ժառանգում է իր կողմից իրականացվող արձանագրության բնութագրերը, ինչը պետք է նշել այստեղ: Արդյունքում, անվտանգության պաշտպանությունը կախված է այն արձանագրությունից, որն օգտագործում է REST-ը:
20. Իդեմպոտենտ մեթոդներ. որո՞նք են դրանք: Ինչպե՞ս է դա վերաբերում RESTful վեբ ծառայությունների աշխարհին:
Երբ URI-ն նույնն է, հարցումի որոշ HTTP մեթոդներ նույն ազդեցությունն են ունենում սերվերի վրա՝ անկախ նրանից, որ դրանք առաքվում են մեկ կամ մի քանի անգամ: Իդեմպոտենտ տեխնիկան դրանք հայտնի են որպես:
Օրինակ, անկախ նրանից, թե GET մեթոդով URI-ն քանի անգամ է գործարկվում, սերվերը միշտ նույն արդյունքը կունենա: Իդեմպոտենտ մեթոդները ներառում են GET, PUT և PATCH, մի քանիսը նշելու համար:
Idempotent HTTP մեթոդները RESTful-ի կողմից օգտագործվողներից են վեբ ծրագրեր. Դրանք անհրաժեշտ են RESTful վեբ ծառայությունների գործունեության հետևողականությունը երաշխավորելու համար:
Հաճախորդները, ովքեր օգտագործում են REST API-ներ, կարող են թույլ տալ կոդի սխալներ, որոնք ստիպում են REST API-ին պատահաբար կրկնվող հարցումներ կատարել: Այս զանգերը ռեսուրսները չարաշահելու ներուժ ունեն:
21. Ո՞րն է HTTP Հիմնական նույնականացման գործառույթը:
Հիմնական նույնականացումը որպես API-ների մաս օգտագործելիս օգտատերը պետք է ներկայացնի օգտվողի անունը և գաղտնաբառը, որոնք զննարկիչի կողմից միացված են «օգտվողի անուն. գաղտնաբառ» և base64 կոդավորված տեսքով:
Բրաուզերից յուրաքանչյուր HTTP հարցման դեպքում կոդավորված արժեքը տրամադրվում է որպես «Լիազորման» վերնագրի արժեք: Քանի որ հավատարմագրերը պարզապես կոդավորված են, խորհուրդ է տրվում օգտագործել այս ձևը HTTPS հարցումներ ուղարկելիս, քանի որ դրանք ապահով չեն և կարող են որևէ մեկի կողմից գաղտնալսվել, եթե անվտանգության արձանագրությունները չօգտագործվեն:
22. Ի՞նչ եք կարծում, GraphQL-ը լավագույն ընտրությունն է միկրոսերվիսային ճարտարապետություն ստեղծելու համար:
Microservices-ը և GraphQL-ը հիանալի կերպով զուգակցվում են, քանի որ GraphQL-ը գաղտնի է պահում ձեր միկրոծառայությունների ճարտարապետությունը ձեր հաճախորդներից:
Առջևի ծայրից դուք ցանկանում եք, որ ձեր բոլոր տվյալները ստացվեն մեկ API-ից, մինչդեռ հետևի մասից դուք ցանկանում եք դրանք բաժանել միկրոծառայությունների: Լավագույն տեխնիկան, որը ես գիտեմ երկուսին էլ հասնելու համար, GraphQL-ի օգտագործումն է:
Այն հնարավորություն է տալիս բաժանել ձեր հետնամասը միկրոծառայությունների, մինչդեռ յուրաքանչյուր հավելվածին տալիս է մեկ API և հնարավորություն է տալիս միանալ տարբեր ծառայությունների տվյալներին:
23. Որո՞նք են հիմնական տարբերությունները անվտանգ և անգործունակ HTTP մեթոդների միջև:
Idempotent մեթոդները տալիս են նույն արդյունքը, երբ մեկ կամ մի քանի անգամ կանչվում են նույն հարցման միջոցով: PUT մեթոդը անիմաստ է:
Բոլոր անվտանգ ուղիներն անզոր են, բայց ոչ բոլոր անպոտենտ մեթոդներն են անվտանգ, քանի որ անվտանգ մեթոդները չեն փոխում ռեսուրսները: Օրինակ, GET-ը ապահով է, քանի որ այն պարզապես վերականգնում է տվյալները և չի փոխում ռեսուրսը:
Բացի այդ, այն անիմաստ է, ինչը նշանակում է, որ այն միշտ կվերադարձնի նույն պատասխանը, երբ կանչվում է:
24. Ի՞նչ է ենթադրում JAX-RS API-ն RESTful Root Resource Classes-ի կողմից:
Java Enterprise Edition-ը տրամադրում է դասեր և միջերեսներ, որոնք համապատասխանում են JAX-RS API-ի պահանջներին: JAX-RS-ի օգնությամբ ավելի հեշտ է դարձել Java վեբ ծառայությունների ստեղծումը REST ճարտարապետական ոճով:
JAX-RS API-ում արմատային ռեսուրսների դասերը պարզապես «պարզ հին java օբյեկտներ» են կամ POJO: Անհրաժեշտ վեբ ռեսուրսներն իրականացնելու համար նրանք օգտագործում են JAX-RS անոտացիաներ:
Նրանք կա՛մ ունեն @path ծանոթագրություններ, կա՛մ նրանց մեթոդներից առնվազն մեկը ունի @path ծանոթագրություններ: Դրանք կարելի է ամփոփել որպես Java դասեր՝ API-ի վերջնակետերի հետ աշխատելու մեթոդներով:
25. Ի՞նչ է կոնկրետ փոստատարը և ինչու է այն օգտագործվում:
API-ի մշակման գործիք, որը կոչվում է Postman, օգտագործվում է API-ներ ստեղծելու, փորձարկելու և փոփոխելու համար: Այս գործիքը կարող է օգտագործվել մշակողների կողմից API-ի համար անհրաժեշտ ցանկացած հատկանիշի համար: Այն հեշտացնում և հեշտացնում է մշակողների աշխատանքը:
Postman-ը հեշտացնում է HTTP-ի մի շարք հարցումներ կատարելը, ներառյալ GET, POST, PUT և PATCH, պահպանում է միջավայրերը հետագա օգտագործման համար և փոխակերպում API-ները կոդերի մի շարք տարբեր լեզուներով:
API-ի ցիկլի յուրաքանչյուր փուլ ավելի պարզ է դառնում Postman-ի հետ, և համագործակցությունն ավելի արագ է մշակվում API-ի ավելի արագ մշակման համար:
Բացի այդ, այն ծրագրավորողներին հնարավորություն է տալիս կառավարել փաստաթղթերը, բնութագրերը, փորձարկման դեպքերը, գործընթացները և API կատալոգները:
26. Ինչպե՞ս են REST API-ները ապահով պահվում:
Քանի որ REST API-ները չեն օգտագործում նույնքան խիստ անվտանգության երաշխիքներ, որքան SOAP API-ները, զգայուն տվյալները չպետք է ուղարկվեն կամ առբերվեն դրանց միջոցով:
Այնուամենայնիվ, վստահելի REST API-ները շարունակում են ինտեգրել անվտանգության վերահսկումները՝ տվյալների անվտանգ և հուսալի փոխանցման համար:
- Նույնականացում և թույլտվություն. API-ին ուղղված յուրաքանչյուր հարցում պետք է անցնի այս երկու ստուգումները: Հաճախորդի ինքնությունը հաստատման միջոցով ստուգելը և թույլտվության միջոցով պահանջվող ռեսուրսներին մուտք գործելու իրավասության հաստատումը երկու տարբեր գործընթացներ են:
- Վավերացում. Մինչ API-ն իր ռեսուրսներին հասանելիություն տրամադրի, նույնականացումից և թույլտվությունից հետո հարցումները դեռ պետք է ստուգվեն հնարավոր վնասակար կոդի համար: Այսպիսով, սերվերը բաց կլինի ներարկման հարձակման համար:
- Վավերացում. Մինչ API-ն իր ռեսուրսներին հասանելիություն տրամադրի, նույնականացումից և թույլտվությունից հետո հարցումները դեռ պետք է ստուգվեն հնարավոր վնասակար կոդի համար: Այսպիսով, սերվերը բաց կլինի ներարկման հարձակման համար:
- Գաղտնագրում. TLS/SSL կոդավորումը պաշտպանում է հաճախորդի և սերվերի միջև կապը և թույլ չի տալիս հաքերներին գաղտնալսել հարցումներն ու պատասխանները:
- Տեմպերի սահմանափակման մեթոդները, ինչպիսիք են սահմանափակումները և շնչափողը, պաշտպանում են սերվերները կոպիտ ուժային հարձակումներից, ինչպիսիք են DDoS-ը, որոնք նպատակ ունեն դրանք նսեմացնել կամ խափանել:
- URI-ներում զգայուն տեղեկություններ չկան. ռեսուրսների URI-ները չպետք է պարունակեն որևէ պաշտպանված տվյալ (օրինակ՝ օգտվողի անուն, գաղտնաբառ կամ նույնականացման նշան):
Եզրափակում
Շնորհավորում եմ: REST API-ի հարցազրույցի մի քանի հիմնական և բարդ հարցեր և դրանց համապատասխան լուծումներն այժմ ձեր մատների տակ են:
Այժմ, երբ լավ պատկերացում ունեք, թե ինչպես պատասխանել REST API-ի որոշ տիպիկ հարցազրույցի հարցերին, կարող եք շարունակել պատասխանել հարցազրույցներին: Հաջորդ քայլը կախված է ձեր նպատակներից:
Այց Հարցազրույցների շարք Հաշդորկի հետ հարցազրույցներին պատրաստվելու համար:
Թողնել գրառում