Երկու առանձին հավելվածների միմյանց շփման համար, անհրաժեշտ է միջնորդ: Այդ պատճառով, ծրագրավորողները կառուցում են կամուրջներ՝ հավելվածների ծրագրային ինտերֆեյսներ կամ API, որպեսզի ապահովեն ինֆորմացիայի կամ ֆունկցիոնալության հասանելիությունը մի համակարգից՝ մյուսը:
Հավելվածների արագ և լայնածավալ ինտեգրմանը նպաստելու համար, API-ները գործարկվում են փոխանցվող հաղորդագրությունների սեմանտիկան ու սինտաքսը որոշող պրոտոկոլների/հաղորդակարգերի և/կամ առանձնահատկությունների միջոցով: Այս առանձնահատկությունները կազմում են API-ի ճարտարապետությունը:
Ժամանակի ընթացքում, ի հայտ են եկել API-ների տարբեր ճարտարապետական ոճեր, որոնցից յուրաքանչյուրն ունի տվյալների փոխանակման իր ստանդարտացման սխեման: Ընտրության բազմազանությունը հաճախ վեճերի առիթ է դառնում, թե ո՞ր ճարտարապետական ոճն է լավագույնը:
Այսօր API-ի շատ օգտատերեր REST-ն անվանում են “Rest in peace” – «Հանգչիր խաղաղությամբ», և ուրախանում GraphQL-ի հաջողությամբ: Մինչդեռ 10 տարի առաջ, իրավիճակը հակառակն էր. REST-ը՝ որպես հաղթող, փոխարինեց SOAP-ին: Այսպիսի կարծիքների սխալը նրանում է կայանում, որ դրանք առաջնահերթ համեմատում են բուն տեխնոլոգիան, առանց հաշվի առնելու դրանց փաստացի կառուցվածքն ու բնութագրերը՝ կոնկրետ իրավիճակում:
Այժմ քննարկենք API-ի ճարտարապետության 4 հիմնական տեսակները, համեմատենք դրանց ուժեղ և թույլ կողմերը և առանձնացնենք այնպիսի սցենարներ, որոնցից յուրաքանչյուրի համար API-ի տվյալ տեսակը լավագույնս է համապատասխանում:
Remote Procedure Call (RPC): գործառույթի կանչ այլ համակարգում
Պրոցեդուրայի/ընթացակարգի հեռավար կանչը (Remote Procedure Call) — դա այլ համատեքստում հեռակա կարգով ընթացակարգ կատարելու առանձնահատկությունն է: RPC-ն ընդլայնում է տեղային՝ լոկալ պրոցեդուրաների կանչի հասկացությունը, բայց տեղավորում է այն HTTP API-ի կոնտեքստում/համատեքստում:
XML-RPC-ի սկզբնական տարբերակի թերությունը կապված է XML-ի օգտակար ծանրաբեռնման համար տվյալների տիպերի ապահովման դժվարությունների հետ: Հետագայում, RPC API-ն սկսեց օգտագործել տիպերն ավելի հստակեցնող JSON-RPC-ն, որը համարվում է SOAP-ի ավելի պարզ այլընտրանքը: gRPC-ը RPC-ի վերջին տարբերակն է, որը մշակվել է Google-ի կողմից՝ 2015 թվականին: Ծանրաբեռնումների հավասարակշռման, հետագծման, աշխատունակության և իսկութան ստուգման միացվող սպասարկման/աջակցման շնորհիվ, gRPC-ն լավ հարմարեցված է միկրոսերվիսների համար:
Ինչպե՞ս է աշխատում RPC-ն
Հայցողը/կլիենտը կանչում է հեռակա պրոցեդուրան, սերիալիզացնում է հաղորդագրության պարամետրերը և լրացուցիչ տեղեկությունները, ուղարկում այդ հաղորդագրությունը սերվերին: Հաղորդագրությունը ստանալուց հետո սերվերը դեսերիալիզացնում է նրա բովանդակությունը, կատարում է պահանջված գործողություններըը և արդյունքը հետ է ուղարկում կլիենտին: Սերվերի և օգտագործողի կողմից իրականացվում է պարամետրերի սերիալիզացիա և դեսերիալիզացիա:
RPC-ի առավելությունները
Փոխազդեցությունների պարզություն և հստակություն: RPC-ն օգտագործում է GET-ը ինֆորմացիայի ստացման համար, իսկ POST-ը՝ մնացած ամեն ինչի համար: Սերվերի և կլիենտի միջև հաղորդակցության մեխանիզմը բերվում է էնդփոինթը(անգլ. endpoint-վերջնակետ, հանգույց) կանչելու և պատասխան ստանալու համար:
Ֆունկցիաների հեշտ ավելացում: API-ի համար նոր պահանջ ստանալուց, մենք հեշտությամբ կարող ենք այդ պահանջն իրականացնող նոր էնդփոինթ ավելացնել. անհրաժեշտ կլինի նոր ֆունկցիա գրել և կցել այն էնդփոինթին: Այսպիսով, կլիենտը կարող է հարցմամբ դիմել տվյալ էնդփոինթին և ստանալ նախնական պահանջներով ձևավորված անհրաժեծտ ինֆորմացիան:
Բարձր արտադրողականություն: Օգտակար ծանրաբեռնվածությունները թեթև են, հեշտությամբ բաշխվում են ցանցի վրա՝ ապահովելով բարձր կատարողականություն, ինչը կարևոր է ընդհանուր սերվերների և աշխատակայանների ցանցերում աշխատող զուգահեռ հաշվարկների համար: RPC-ն ի վիճակի է օպտիմիզացնել ցանցային մակարդակը և այն շատ արդյունավետ դարձնել մի իրավիճակում, երբ տարբեր ծառայություններ ամեն օր տոննաներով հաղորդագրություններ են փոխանակում:
RPC-ի թերությունները
Բազային համակարգի հետ ամուր կապը: API-ի աբստրակցիայի մակարդակը հնարավորություն է ստեղծում բազմակի կիրառույուն ապահովելու: Միևնույն ժամանակ, որքան ավելի սերտ է կապը բազային համակարգի հետ, այնքան ավելի վատ է API-ն համապատասխանում այլ համակարգերի համար: RPC-ի սերտ կապը բազային համակարգի հետ թույլ չի տալիս աբստրակցիոն շերտ ստեղծել համակարգի ֆունկցիաների և արտաքին API-ի միջև: Սա անվտանգության խնդիրների է բերում, քանի որ բազային համակարգի իրագործման մանրամասները բավականին հեշտությամբ արտահոսում են դեպի API: RPC-ի ամուր միացումը մարտահրավերներ է ստեղծում մասշտաբայնության պահանջների և թույլ միացված թիմերի համար: Այսպիսով, կլիենտը կա՛մ փորձում է խուսափել կոնկրետ էնդփոինթի դիմելու հնարավոր կողմնակի ազդեցություններից, կա՛մ փորձում է պարզել, թե որ էնդփոինթին է անհրաժեշտ դիմել, քանի որ չի հասկանում, թե ինչ սկզբունքով է սերվերը անվանակոչել ֆունկցիաները:
Ցածր հայտնաբերելիություն: RPC-ում API-ն հետևելու, ինսպեկցիա կամ ուղիղ դեբագ անելու ուղիղ միջոց չկա: Հարցումների մշակման ժամանակ դժվար է հասկանալ, թե որ ֆունկցիան է աշխատում տվյալ պահին:
Ֆունկցիների պայթյուն: Նոր ֆունկցիաները շատ արագ և հեշտ են ինտեգրվում, ինչի պատճառով եխածները փոփոխելու փոխարեն, շատ հաճախ պարզապես նորերն են ստեղծվում, ինչի արդյունքում ստանում ենք մեծածավալ իրար ծածկող ֆունկցիաների ցանկ, որոնց մեջ կողմնորոշվելը դժվար է դարձնում սպասարկումը:
RPC-ի օգտագործման օրինակներ
RPC-ն սկսել է կիրառվել դեռևս 1980-ականներից, բայց միայն դա չի դարձնում այն հնացած: Խոշոր ընկերությունները, ինչպիսիք են Google-ը, Facebook-ը (Apache Thrift) և Twitch (Twirp), իրենց ներսում օգտագործում են բարձր արդյունավետությամբ RPC վարիացիաներ՝ ցածր ռեսուրսատարությամբ, բայց և գերբարձր արդյունավետությամբ հաղորդագրությունների փոխանակման կազմակերպման համար: Նրանց միկրոսերվիսների հսկայական համակարգերը պահանջում են, որ ներքին հաղորդակցությունը լինի պարզ, արագ և միևնույն ժամանակ կազմակերպված կարճ հաղորդագրությունների տեսքով:
API հրամանների համար: RPC-ն լավ ընտրություն է հեռավար համակարգին հրամաններ ուղարկելու համար: Օրինակ, Slack API-ն շատ թիմ-կոմնորոշված է. մուտք գործել ալիք, լքել ալիքը, հաղորդագրություններ ուղարկել: Slack API-ի մշակողները այն մոդելավորել են հենց RPC ոճով՝ դարձնելով այն փոքր, կոմպակտ և հեշտ օգտագործման համար:
Կլիենտ API-ներ՝ ներքին միկրոսերվիսների համար: Միակ մատակարարի և սպառողի միջև ուղղակի ինտեգրման դեպքում ցանկալի չէ շատ ժամանակ ծախսել մեծ քանակությամբ մետատվյալների փոխանցման վրա, ինչպես դա անում է REST API-ն: gRPC-ն և Twirp-ը շատ հարմար են միկրոսերվիսների համար՝ հաղորդագրությունների իրենց բարձր արագության և կատարողականի շնորհիվ: gRPC-ն՝ HTTP2-ի տակ, ի վիճակի է օպտիմիզացնել ցանցի շերտը և այն ավելի արդյունավետ դարձնել, եթե օրական մեծածավալ հաղորդագրություններ է ուղարկվում մի ծառայությունից մյուսը: Այնուամենայնիվ, եթե ձեր նպատակը ոչ թե ցանցի բարձր արդյունավետությունն է, այլ շատ տարբեր միկրոսերվիսներ թողարկող թիմերի միջև կայուն API կապը, REST-ը ավելի լավ կհոգա այդ մասին:
Simple Object Access Protocol (SOAP): տվյալների ներկայացում սերվիսների տեսքով
SOAP-ը կամ պարզ օբյեկտների մուտքի պրոտոկոլը, դա XML-ի վրա հիմնված, վեբ հաղորդակցության բարձր ստանդարտացված պրոտոկոլ է: Microsoft-ի կողմից XML-RPC-ից մեկ տարի անց թողարկված SOAP-ը շատ բան է ժառանգում դրանից: Երբ REST-ը մտավ ասպարեզ, սկզբում դրանք կիրառվեցին զուգահեռ, բայց շուտով REST-ը հաղթեց հանրաճանաչության մրցույթում։ SOAP-ն ի սկզբանե նախատեսված էր պրոցեդուրայի հեռավար կանչ՝ RPC իրագործելու համար: Այժմ այն օգտագործվում է ոչ միայն պրոցեդուրալ կանչերի, այլև կամայական XML հաղորդագրություններ փոխանակելու համար: SOAP-ը կարող է օգտագործվել հավելվածի ցանկացած մակարդակի պրոտոկոլի հետ՝ SMTP, FTP, HTTP, HTTPS և այլն: Այնուամենայնիվ, դրա փոխազդեցությունը սրանցից յուրաքանչյուրի հետ ունի իր առանձնահատկությունները, որոնք պետք է սահմանվեն առանձին: Ամենից հաճախ SOAP-ն օգտագործվում է HTTP-ի միջոցով: SOAP-ը ստանդարտներից մեկն է, որի վրա հիմնված են վեբ տեխնոլոգիաները:
Ինչպե՞ս է աշխատում SOAP-ը
XML ֆորմատը գալիս է բազմաթիվ ձևականություններով: Հաղորդագրության զանգվածային կառուցվածքի հետ համակցված՝ այն SOAP-ը դարձնում է API-ների ամենամանրամասն ոճը:
SOAP-հաղորդագրությունները ունեն հետևյալ կառուցվածքը.
Envelope– գլխավոր էլեմենտը, որը սահմանում է փաստաթղթում օգտագործվող հաղորդագրությունը և անվանատարածքը: Սրանով սկսվում և վերջանում են բոլոր հաղորդագրությունները:Header– պարունակում է հաղորդագրության ատրիբուտները, գլխագրերը, ինչպիսիք են անվտանգության կամ ցանցային երթուղիչի մասին տեղեկատվությունը:Body– պարունակում է հավելվածների միջև փոխանակվող հաղորդագրությունը, հարցումն ու պատասխանը:Fault– ոչ պարտադիր էլեմենտ, որը տեղեկատվություն է տրամադրում հաղորդագրությունների մշակման ընթացքում տեղի ունեցած սխալների մասին:
SOAP API-ի տրամաբանությունը գրված է Web Services Description Language(Վեբ ծառայությունների նկարագրության լեզվով` WSDL): API-ի նկարագրության այս լեզուն սահմանում է էնդփոինթը և նկարագրում է բոլոր գործընթացները, որոնք կարող են իրականացվել: Սա թույլ է տալիս տարբեր ծրագրավորման լեզուներին և IDE-ներին արագ շփում հաստատել:
SOAP-ն աջակցում է հաղորդագրությունների փոխանակումը դրանց վիճակը հետևելով և առանց(stateful/stateless): Վիճակի փոփոխության հետևելու սցենարի դեպքում սերվերը պահպանում է ստացված ինֆորմացիան, որը կարող է շատ մեծ լինել: Բայց դա արդարացված է բազմակողմ օպերացիաների և բարդ տրանզակցիաների համար։
SOAP-ի առավելությունները
Լեզվից և հարթակից անկախ: Վեբ ծառայությունների ստեղծման համար ներկառուցված ֆունկցիոնալությունը թույլ է տալիս SOAP-ին մշակել հաղորդագրությունները և դարձնել պատասխանների լեզուն և հարթակը անկախ:
Միացում տարբեր տրանսպորտային պրոտոկոլների հետ: Փոխանցման պրոտոկոլների տեսանկյունից SOAP-ը բավականին ճկուն է և հարմարեցվում է մեկից ավելի սցենարների:
Սխալների ներկառուցված մշակում: SOAP API-ի առանձնահատկությունը թույլ է տալիս վերադարձնել Retry XML հաղորդագրություն՝ սխալի կոդով և բացատրությամբ:
Մի շարք անվտանգային հավելումներ: WS-Security պրոտոկոլների հետ ինտեգրվելու շնորհիվ SOAP-ի տրանզակցիաների որակը համապատասխանում է կորպորատիվ չափանիշներին: SOAP-ը երաշխավորում է գաղտնիությունն ու ամբողջականությունը գործարքների ընթացքում՝ միաժամանակ ապահովելով ծածկագրումը հաղորդագրությունների մակարդակում:
SOAP-ի թերությունները
Միայն XML: SOAP հաղորդագրությունները պարունակում են շատ մետատվյալներ և աջակցում են միայն մանրամասն XML կառուցվածքներ հարցումների և պատասխանների համար:
Ծանրաքաշություն: XML ֆայլերի մեծ ծավալի պատճառով SOAP ծառայությունները պահանջում են մեծ թողունակություն:
Նեղ մասնագիտական գիտելիքների պահանջ: SOAP API սերվերների կառուցումը պահանջում է ներգրավված բոլոր պրոտոկոլների և դրանց խիստ կանոնների մասին խորը պատկերացում:
Հաղորդագրությունների դանդաղ թարմացում: Հաղորդագրության հատկությունները ավելացնելու կամ հեռացնելու համար պահանջվում է լրացուցիչ ջանք, քանզի SOAP-ի խիստ սխեման դանդաղեցնում է փոփոխությունների ընդունումը:
SOAP-ի օգտագործման սցենարներ
Ներկայումս SOAP ճարտարապետությունն առավել հաճախ օգտագործվում է ձեռնարկությունների ներսում կամ նրանց վստահելի գործընկերների հետ ինտեգրվելու համար:
Տվյալների փոխանցման հուսալիություն: SOAP-ի կոշտ կառուցվածքը, ինչպես նաև նրա անվտանգության և նույնականացման հնարավորությունները այն դարձնում են ամենահարմար տարբերակը API-ի և հաճախորդի միջև ֆորմալ ծրագրային կոնտրակտին համապատասխանությունն ապահովելու համար՝ միաժամանակ հետևելով API մատակարարի և API սպառողի միջև իրավական պայմանագրերին: Ահա թե ինչու ֆինանսական հաստատությունները և այլ կորպորատիվ օգտատերերն ընտրում են SOAP-ը:
Նկարագրությունների վիճակի փոխանցում (REST): տվյալների տրամադրում որպես ռեսուրսներ
REST-ը (անգլ.՝ Representational State Transfer) API-ների ինքնանկարագրող ճարտարապետոական ոճ է, որոշված ճարտարապետության սահմանափակումների փաթեթով, նախատեսված բազմաթիվ API սպառողների կողմից լայն ներդրման համար:
API-ի նորկայումս ամենամեծ տարածումն ունեցող ձևն առաջին անգամ նկարագրվել է 2000 թվականին Ռոյ Ֆիլդինգի դոկտորական դիսերտացիայում: REST-ը հասանելի է դարձնում տվյալները սերվերի կողմում, ներկայացնելով դրանք պարզ՝ հիմնականում JSON և XML ֆորմատներով:
Ինչպես է աշխատում REST-ը
REST-ը SOAP-ի նման խիստ սահմանված չէ: RESTful-ճարտարապետությունը պետք է համապատասխանի 6 ճարտարապետական սահմանափակումների.
- միասնական ինտերֆեյս, որը թույլ կտա միանման փոխազդեցություն սերվերի հետ, անկախ սարքից կամ հավելվածից
- վիճակի բացակայություն. հարցման մշակման համար պահանջվող վիճակը պարունակվում է հենց հարցման մեջ՝ առանց սերվերի կողմից սեսիայի հետ կապված որևէ տվյալ պահելու
- քեշավորում
- հաճախորդ-սերվերային ճարտարապետություն, որը թույլ է տալիս երկու փոխազդող կողմերի միմյանցից անկախ զարգացում
- հավելվածի բազմաշերտ կառուցվածք
- սերվերի համար հնարավորություն ապահովել կատարվող կոդը հաճախորդի կողմում.
Իրականում, որոշ ծառայություններ համապատասխանում են RESTful ստանդարտին միայն մասնակիորեն: Նրան որպես հիմք վերցնում են RPC ոճը, առավել խոշոր սերվիսները բաժանում են ռեսուրսների և արդյունավետորեն օգտագործում են HTTP ինֆրաստրուկտուրան: Բայց առանցքայինն այստեղ հիպերմեդիան է, կամ HATEOAS-ը, որը “Հիպերտեքստը որպես հավելվածի վիճակի շարժիչ” (Hypertext As The Engine of Application State) անգլերեն ասույթի կրճատ ձևն է: Գործնականում սա նշանակում է, որ յուրաքանչյուր պատասխանի հետ REST API-ն ներկայացնում է մետատվյալներ (metadata), որոնք API-ի օգտագործման ողջ ինֆորմացիան իրար են կապում: Սա այն է, ինչը հնարավորություն է տալիս առանձնացնել կլիենտին սերվերից: Արդյունքում, և API տրամադրողը, և այն օգտագործողը կարող են զարգանալ և փոփոխվել միմյանցից անկախ՝ առանց հաղորդակցման դժվարություններ առաջացնելու:
Եվ իսկապես, HATEOAS-ը REST-ի ամենահասուն և ավարտուն տարբերակն է: Սակայն այս նպատակին հասնելը բավականին դժվար է: Դրա համար նախ պահանջվում է ժամանակակից գործածության մեջ հանդիպածներից էլ ավելի զարգացած և ինտելեկտուալ API կլիենտներ: Այս կերպ՝ նույնիսկ իսկապես լավ նախագծված REST API-ին այսօր չի համապատասխանում ստանդարտին: Ահա թե ինչու HATEOAS-ը հիմնականում ծառայում է որպես կողմնորոշիչ՝ RESTful API-ների դիզայնի երկարաժամկետ զարգացման համար:
REST-ի և RPC-ի միջև իսկապես կարող է գորշ տիրույթ լինել, երբ սերվիսն իրագործում է մասամբ REST ֆունկցիաներ՝ ռեսուրսի հիման վրա(գոյական), մասամբ՝ RPC, գործողության վրա հիմնված(ածական) ֆունկցիաներ:
REST-ում ամեն ինչ արվում է հիմնվելով HTTP-մեթոդների վրա, ինչպիսիք են GET, POST, PUT, DELETE, OPTIONS, PATCH:
REST-ի առավելությունները
Կլիենտի և սերվերի առանձնացում Հնարավորության չափով բաժանելով հաճախորդին սերվերից, REST-ն ապահովում է ավելի լավ աբստրակցիա, քան RPC-ն: Աբստրակցիոն շերտերով համակարգը ի վիճակի է ամփոփել, ինկապսուլացնել իր իսկ մանրամասները, սեփական հատկություններն ավելի լավ իդենտիֆիկացնելու և ապահովելու համար: Հետևաբար, REST API-ն բավական ճկուն է ժամանակի ընթացքում զարգանալու և դեռ կայուն համակարգ մնալու համար:
Բացություն: Ամեն ինչ նկարագրվում է հաճախորդի և սերվերի միջև հաղորդակցության միջոցով, ուստի հասկանալու համար, թե ինչպես փոխազդել REST API-ի հետ, որևէ արտաքին դոկումենտացիայի խիստ անհրաժեշտություն չկա:
Քեշավորման հանդեպ հարմարվածություն: REST-ը միակ տարբերակն է, որը հնարավորություն է տալիս քեշավորել տվյալները HTTP-ի մակարդակում, բազմաթիվ HTTP գործիքների օգտագործման շնորհիվ: Այն դեպքում, երբ յուրաքանչյուր այլ API-ի դեպքում քեշավորման իրականացումը կպահանջի առնվազն լրացուցիչ քեշավորման մոդուլի օգտագործում:
Տարբեր ֆորմատների ապահովում: Տվյալների պահպանման և փոխանակման համար բազմաթիվ ֆորմատների աջակցելու հնարավորությունը պատճառներից մեկն է, թե ինչու REST-ը ներկայումս գերիշխում է համահասանելի, հանրային օգտագործման և բաց API-ների ստեղծման ոլորտում:
REST-ի թերությունները
Չկա REST-ի միասնական ստրուկտուրա: Չկա REST API ստեղծելու որպես ճիշտ սահմանված հստակ եղանակ: Ինչպես մոդելավորելռեսուրսները և ինչպիսի ռեսուրսներ մոդելավորել, կախված է կոնկրետ սցենարից: Սա REST-ը դարձնում է տեսականորեն հեշտ, պրակտիկորեն՝ դժվար:
Մեծ օգտակար բեռնվածք: RESTը վերաադարձնում է հարուստ մետատվյալների այնպիսի մի ամբողջական ցանկ, որն իրենով բավարար է հասկանալու հավելվածի կարգավիճակը: Սա իհարկե մեծ առավելություն է կլիենտի համար, հաշվի առնելով նաև, որ նման տվյալների ծավալը զգալի ազդեցություն չի ունենում մեծ թողունակություն ունեցող ցանցի համար: Բայց այս պատկերը ոչ միշտ է դիտարկվում: Հենց նման բեռնվածքների ու ցանցի վրա առաջացրած ծանրաբեռնումն էր հիմնական գործոնը, որը ստիպեց Facebook-ին դեռևս 2012-ին ստեղծել GraphQL-ը:
Չափից դուրս շատ կամ անբավարար տվյալներ: REST-ի պատասխանները շատ հաճախ պարունակում են կամ անհրաժեշտից շատ տվյալներ, որն ուղղակի անօգուտ է տվյալ պարագայում, կամ քիչ տվյալներ, որոնք անհրաժեշտություն են ստեղծում լրացուցիչ հարցում իրականացնել:
REST-ի կիրառման սցենարներ
Կառավարման API-ինտերֆեյսներ: Համակարգում օբյեկտների կառավարմանը կողմնորոշված և բազմաթիվ օգտագործողների համար նախատեսված API-ներն ամենալայն տարածումն ունեն: REST-ն օգնում է նման API-ներին, ապահովելով ուժեղ հայտնաբերվածություն և լավ դոկումենտացիա, այդպիսով տեղավորվելով է այս օբյեկտային մոդելում:
Ռեսուրսների կողմից կառավարվող պարզ հավելվածներ: REST-ը ռեսուրսների կողմից կառավարվող հավելվածների միացման համար, որոնք հարցումների ճկունության կարիք չունեն և կատարում են ֆիքսված հարցում, ակնկալելով ֆիքսված մինիմալ պատասխան:
GraphQL: միայն անհրաժեշտ տվյալների հարցում
Որպեսզի ինչ-որ անհրաժեշտ տվյալներ ստանալ, REST API-ով հաճախ անհրաժեշտ է լինում բազմաթիվ հարցումներ անել: Եվ խաղի կանոնները փոխելու համար մշակվեց GraphQL-ը:
GraphQL-ը սինտաքս է, որը նկարագրում է, թե ինչպես անել հստակ հարցումներ: GraphQL-ի ռեալիզացիան առավել օգտակար է դառնում, հավելվածի տվյալների մոդելը կիրառվում է մեծ թվով բարդ սուբյեկտների հետ, որոնք հղում են կատարում միմյանց:
Մեր օրերում GraphQL-ի էկոսիստեման ընդլայնվում է գրադարանների ու հզոր այնպիսի գործիքների միջոցով, ինչպիսիք են Apollo, GraphiQL и GraphQL Explorer:
GraphQL-ի աշխատանքի սկզբունքը
GraphQL-ը սկսվում է սխեմայի կառուցմամբ, որն իրենից ներկայացնում է բոլոր հարցումների ու տվյալների բոլոր տիպերի նկարագրություն, որոնք հնարավոր է անել GraphQL API-ի միջոցով և ինչ նա կարող է վերադարձնել: Սխեմայի կառուցումը դժվար առաջադրանք է, քանզի այն պահանջում է խիստ տիպիզացում սխեմաների որոշման լեզվով (Schema Definition Language, SDL):
Նախքան հարցումն ուղարկելը, վերոնշյալ սխեմային տիրապետող կլիենտը կարող է հարցում ուղարկել, համոզվելու համար, որ սերվերը կարող է պատասխանել իրեն: Հասնելով բեքենդ, GraphQL-ի օպերացիան ինտերպրետացվում է ամբողջ սխեմայով, և թույլատրվում է ֆրոնտի տվյալների միջոցով: Սերվերին ուղարկելով մեկ զանգվածային հարցում՝ API-ն վերադարձնում է JSON պատասխան՝ հենց մեր պահանջած տվյալներով:
Ի լրումն CRUD գործողությունների, RESTful GraphQL-ը պարունակում է նաև բաժանորդագրություններ, որոնք թույլ են տալիս իրական ժամանակում ստանալ ծանուցումներ սերվերից:
GraphQL-ի առավելությունները
Տիպիզացված սխեմա: GraphQL-ը նախապես հրապարակում է այն, ինչ կարող է իրագործել, ինչը բարելավում է հայտնաբերելիությունը: Կլիենտին GraphQL API-ին հասանելիություն տալով, մենք կարող ենք պարզել, թե ինչ հարցումներ են հասանելի:
Հարմար է գրաֆիկական տվյալների համար: Տվյալներ, որոնք գտնվում են խորը կապերի մեջ, բայց հարմար չեն հարթ տվյալների համար:
Ոչ մի վերսիա: Պարադոքսալ է հնչում, բայց տարբերակման լավագույն պրակտիկան – API-ն ընդհանրապես չտարբերակելն է: Այն դեպքում, երբ REST-ն առաջարկում է API-ի մի քանի վերսիաներ, GraphQL-ն օգտագործում է միասնական, զարգացող վերսիա, որն ապահովում է շարունակական հասանելիություն դեպի նոր հնարավորություններ և խթանում է ավելի մաքուր և սպասարկման համար հեշտ սերվերային կոդի:
Սխալների մանրամասն նկարագրություն: SOAP-ի նման, GraphQL-ը նույնպես սխալների մասին մանրամասն ինֆորմացիա է տրամադրում: Սխալի հաղորդագրությունը ներառում է բոլոր լուծումները(resolver) և վերաբերում է հարցման կոնկրետ մասին, որը պատասխանատու է սխալի առաջացման համար:
Ճկուն թույլատրություններ: GraphQL-ը թույլ է տալիս ընտրողաբար բացահայտել որոշ ֆունկցիաներ՝ պահպանելով անձնական տվյալները: Միևնույն ժամանակ, REST ճարտարապետությունը չի բացահայտում տվյալները մասնակի. դրանք կամ լրիվ հասանելի են, կամ բացարձակ անհասանելի:
GraphQL-ի թերությոյւնները
Արագագործության խնդիր: GraphQL-ը կատարողականը զոհում է բարդությանը: Մեկ հարցման մեջ չափազանց շատ ներկառուցված դաշտերի առկայությունը կարող են ծանրաբեռնել համակարգը: Այսպիսով, բարդ հարցումների դեպքում REST-ը մնում է լավագույն տարբերակը:
Քեշավորման բարդություն: Քանի որ GraphQL-ը չի վերաօգտագործում HTTP քեշավորման սեմանտիկան, GraphQL-ի քեշավորումը կողմնակի հավելվածների կարգաբերում է պահանջում:
GraphQL-ի օգտագործման սցենարներ
Բջջային API: Այս դեպքում կարևոր են ցանցի կատարողականը և մեկ հաղորդագրության օգտակար բեռի օպտիմալացումը: Եվ GraphQL-ն առաջարկում է ավելի արդյունավետ տվյալների բեռնում բջջային սարքերի համար:
Բարդ համակարգեր և միկրոսերվիսներ: GraphQL-ն ի վիճակի է թաքցնել իր API-ների հիմքում ընկած բազմաթիվ ինտեգրված համակարգերի բարդությունը: Տարբեր աղբյուրներից տվյալներ հավաքելով՝ այն միավորում է դրանք մեկ գլոբալ սխեմայի մեջ: Սա հատկապես արդիական է հնացած ինֆրաստրուկտուրաների կամ կողմնակի API-ների համար, որոնք ժամանակին համընթաց ընդլայնվել են:
API-ների ո՞ր տարբերակն է համապատասխանում Ձեզ
Յուրաքանչյուր նախագծային API ունի իր պահանջներն ու կարիքները: Որպես կանոն, ճարտարապետության ընտրությունը կախված է.
- ծրագրավորման լեզվից
- ծրագրավորման միջավայրից
- ռեսուրսներ, որոնք պետք է խնայվեն, ինչպես մարդկային, այնպես էլ ֆինանսական:
Հասկանալով փոխզիջումները, որոնք առաջ են մղում ճարտարապետության յուրաքանչյուր ոճ, API ճարտարապետները կարող են ընտրել այն մեկը, որը լավագույնս համապատասխանում է կոնկրետ նախագծին:
Իր ուժեղ կապակցվածության շնորհիվ RPC-ն լավ հարմարեցված է ներքին միկրոծառայությունների համար, սակայն այն տարբերակ չէ ուժեղ արտաքին API կամ API ծառայության համար:
SOAP – խրթին է, բայց դրա ընդգրկուն ֆունկցիոնալն անվտանգության տեսանկյունից դեռևս անփոխարինելի է վճարային գործողությունների, ամրագրման համակարգերի և վճարումների համար:
REST-ն ունի ամենաբարձր աբստրակցիան և լավագույն API մոդելավորումը: Սակայն ցանցի ծանրաբեռնվածության առումով այն ավելի ծանր է, և ավելի մանրամասն. թերություն, եթե խոսքը բժժային հավելվածի մասին է:
GraphQL — մեծ առաջընթաց է տվյալների արդյունահանման առումով, բայց ոչ բոլորն ունեն այն տիրապետելու ժամանակ կամ հնարավորություն:
Ի վերջո, իմաստ ունի փորձել որոշակի ճարտարապետական ոճով մի քանի փոքր սցենարներ և տեսնել, թե արդյոք այն համապատասխանում է և լուծում է ձեր խնդիրները: Եթե այո, փորձեք ընդլայնել այն և տեսնել, թե ինչպես են աշխատում ավելի շատ օգտագործման դեպքերի համար:
Սկզբնաղբյուր՝ Comparing API Architectural Styles: SOAP vs REST vs GraphQL vs RPC
