Ցանկանու՞մ եք կապել ձեր հավելվածը Facebook-ի հետ, որպեսզի այն կարողանա ավտոմատ կերպով հրապարակումներ ստեղծել, թե՞ Instagram-ին, որպեսզի կարողանաք վերահաստատել լուսանկարներ որոշակի հեշթեգներով:
Կարող եք նաև ցանկանալ YouTube-ի տեսանյութեր ներառել ձեր կայքում: Հավելվածների ծրագրավորման միջերեսները թույլ են տալիս կատարել այս բոլոր առաջադրանքները և ավելին (API):
Տարբեր հավելվածներ կարող են «խոսել» միմյանց հետ անվտանգ և ստանդարտացված ձևով API-ների շնորհիվ, ինչպիսիք են Instagram API-ն, Facebook API-ն և YouTube API-ն:
Այլ կերպ ասած, ծրագիրը կարող է վերցնել առանձնահատկություններ կամ տվյալներ ծրագրաշարի մեկ այլ մասից և օգտագործել դրանք՝ բարելավելու իր սեփական հնարավորությունները կամ օգտագործողի փորձը: Բայց ինչպե՞ս կարող են հավելվածները կատարել այս հարցումները, մշակել դրանք և պատասխանել ուրիշներին հասկանալի ձևով:
Դա կախված է նրանից, թե ինչպես է ստեղծվել API-ն: API-ի (հավելված ծրագրավորման ինտերֆեյսի) ձևավորումները քննարկելիս սովորական է համեմատել SOAP-ն ընդդեմ REST-ի՝ երկու ամենահայտնի API պարադիգմների:
Հենց որ SOAP API-ները (Simple Object Access Protocol) դարձան ոսկու ստանդարտ այնպիսի ընկերությունների համար, ինչպիսիք են Oracle-ը, Sun-ը և PayPal-ը, մեկ տարի անց հավասար և հակառակ արձագանք եղավ Google-ի, Amazon-ի և eBay-ի REST API-ների նկատմամբ:
Այս գրառման մեջ մենք կհամեմատենք և կհակադրենք SOAP API-ները REST API-ների հետ, որպեսզի կարողանաք որոշել, թե որն է լավագույնը ձեր նպատակների համար:
Մենք կսկսենք API-ի սահմանմամբ:
Ինչ է API-ն:
Հավելվածի ծրագրավորման ինտերֆեյսը կոչվում է API: API-ները հիմնականում մեթոդների և գործառույթների հավաքածու են, որոնք հնարավորություն են տալիս հավելվածների մշակմանը: Նրանք հասանելի են դառնում տարբեր ծրագրերի, ծառայությունների կամ օպերացիոն համակարգերի տեղեկատվությանն ու գործառույթներին:
Նրանք ծառայում են որպես մի տեսակ միջնորդ տարբեր ծրագրային համակարգերի միջև: Նրանք հնարավորություն են տալիս «խոսել» երկու չկապված ծրագրերի միջև:
Վերցնենք ֆոնդային բրոքերի օրինակը, ով ակտիվորեն ներգրավված է առևտրի և ֆինանսական շուկաների մեջ: Ավտոմատացված հավաքածու առևտրային ալգորիթմներ կարող է միացված լինել վաճառողի սիրելի առևտրային բրոքերային հարթակին API-ի միջոցով: Սա ձեզ՝ վաճառողին, հնարավորություն է տալիս իրականացնել էլեկտրոնային գործարքներ կամ տեսնել իրական ժամանակի գնանշումները և գնային տվյալները:
Ի՞նչ է ՀԱՆԳՍՏՈՒՄԸ:
Իսկական «վեբ ծառայությունների» API-ները ներառում են REST (Ներկայացուցչական պետական փոխանցում): REST API-ները կառուցված են URI-ների (Միասնական ռեսուրսների նույնացուցիչներ, որոնցից URL-ը հատուկ տեսակ է), HTTP արձանագրության և բրաուզերի հետ անհավանական համատեղելի JSON տվյալների ձևաչափի վրա:
SOAP արձանագրությունը, ինչպես արդեն նշեցինք, հնարավոր է նաև օգտագործվի: REST API-ները կարող են հեշտ լինել ստեղծել և աճել, բայց դրանք կարող են նաև լինել հսկայական և դժվար, ամեն ինչ կախված է նրանից, թե ինչպես են դրանք ստեղծվել, ընդլայնվել և ինչ են պատրաստվում անել:
Ռեսուրսների սահմանափակումները, անվտանգության նվազեցված պահանջները, բրաուզերի հաճախորդի համատեղելիությունը, հայտնաբերելիությունը, տվյալների առողջությունը և մասշտաբայնությունը որոշ պատճառներ են, որոնց համար կցանկանայիք մշակել API՝ Հանգստացնող լինելու համար. բաներ, որոնք իրականում վերաբերում են վեբ ծառայություններին:
REST-ն առաջարկում է ավելի թեթև տարբերակ: SOAP-ը դժվար էր օգտագործել և ծանրաբեռնել շատ մշակողների համար: Օրինակ, JavaScript-ով SOAP-ի օգտագործումը պահանջում է շատ կոդ գրել՝ պարզ գործողություններ ավարտելու համար, քանի որ անհրաժեշտ XML կառուցվածքը պետք է ստեղծվի ամեն անգամ:
REST-ը (սովորաբար) XML հարցման փոխարեն օգտագործում է պարզ URL: Չնայած կան հազվադեպ հանգամանքներ, երբ դուք պետք է ավելի շատ մանրամասներ առաջարկեք, RESTful վեբ ծառայությունների մեծամասնությունը օգտագործում է միայն URL տեխնիկան:
GET, POST, PUT և DELETE չորս HTTP 1.1 բայերը կարող են օգտագործվել REST-ի կողմից՝ գործողություններ իրականացնելու համար: Ի տարբերություն SOAP-ի, REST-ը կարիք չունի, որ պատասխանը լինի XML-ում:
Հասանելի են REST-ի վրա հիմնված վեբ ծառայություններ, որոնք տվյալներ են թողարկում Command Separated Value (CSV), JavaScript Object Notation (JSON) և Really Simple Syndication (RSS) ձևաչափերով (RSS):
Նպատակն այն է, որ դուք կարողանաք ստանալ ձեզ անհրաժեշտ արդյունքները հեշտ վերլուծվող ձևաչափով այն լեզվով, որն օգտագործում եք ձեր հավելվածի համար:
Հատկություններ
- REST-ն ամենից առաջ ընդգծում է պարզությունը՝ շնորհիվ HTTP արձանագրությունների:
- Վեբը լավագույնս հարմար է ՀԱՆԳՍՏԻ համար: Այն համատեղելի է բրաուզերների հետ, քանի որ JSON-ն օգտագործվում է որպես տվյալների ձևաչափ:
- REST-ը հայտնի է իր ակնառու մասշտաբայնությամբ և արագությամբ:
- Հաճախորդ-սերվեր կապերը և ճարտարապետությունը ավելի հասանելի են դարձնում REST API-ները: Եթե այն RESTful է, ապա այն կառուցված է հաճախորդ-սերվերի այս մոդելի միջոցով, երկու կողմերի միջև կլոր շրջագայություններով, որոնք փոխանցում են տվյալների ծանրաբեռնվածությունը:
- REST API-ներն օգտագործում են միայնակ ստանդարտ ինտերֆեյս: Ապահովելով, որ բոլոր հավելվածները միանում են միատեսակ և միևնույն դարպասի միջոցով, պարզեցնում է, թե ինչպես են հավելվածները հաղորդակցվում API-ի հետ:
Ի՞նչ է SOAP-ը:
Իր սեփական արձանագրությունը, որը կոչվում է SOAP (Simple Object Access Protocol), մի փոքր ավելի բարդ է, քան REST-ը, քանի որ այն սահմանում է ավելի շատ ստանդարտներ, ներառյալ անվտանգության և հաղորդագրությունների առաքման հետ կապված:
Այս բնորոշ նորմերը գալիս են մի փոքր ավելորդ ծախսերի հետ: Այնուամենայնիվ, դրանք կարող են որոշիչ գործոն լինել այն ձեռնարկությունների համար, որոնք կարիք ունեն ավելի լայն անվտանգության, գործարքների և ACID (Ատոմականություն, հետևողականություն, մեկուսացում, երկարակեցություն) համապատասխանության հնարավորությունների:
Այս համեմատության համար կարևոր է նշել, որ SOAP-ի առավելություններից շատերը հաճախ չեն վերաբերում վեբ ծառայությունների հավելվածներին, ինչը նրանց ավելի հարմար է դարձնում ձեռնարկության տիպի սցենարների համար:
Անվտանգության ավելի բարձր աստիճաններ (օրինակ, երբ ա բջջային ծրագիրը փոխազդում է բանկի հետ), հաղորդագրությունների հավելվածները, որոնք պահանջում են հուսալի հաղորդակցություն, հին համակարգերի հետ փոխգործակցությունը կամ ACID-ի համապատասխանությունը մի քանի պատճառներ են, որոնց համար կցանկանայիք նախագծել հավելված՝ օգտագործելով SOAP API:
SOAP-ի կողմից առաջարկվող հաղորդագրությունների հնարավորություններն ամբողջությամբ հիմնված են XML-ի վրա: Համացանցի հետ անհամատեղելի հին տեխնոլոգիաները, ինչպիսիք են Distributed Component Object Model-ը (DCOM) և Common Object Request Broker Architecture-ը, փոխարինվել են SOAP-ով, երբ այն առաջին անգամ ստեղծվել է Microsoft-ի (CORBA) կողմից:
Երկուական հաղորդակցությունների վրա կախվածությունը հանգեցնում է այս համակարգերի ձախողմանը: Ինտերնետում SOAP-ի կողմից օգտագործվող XML հաղորդագրություններն ավելի լավ են գործում:
Հատկություններ
- SOAP-ի անվտանգությունը զգալիորեն խստացված է։ WS-Security-ը ներկառուցված ստանդարտ է, որն առաջարկում է SOAP լրացուցիչ ձեռնարկության մակարդակի անվտանգության հնարավորություններ, եթե անհրաժեշտ է, բացի SSL աջակցությունից:
- Հաջող/կրկին փորձեք պատճառաբանել վստահելի հաղորդագրությունների կատարման համար: Քանի որ REST-ը չունի ստանդարտացված հաղորդագրության մեխանիզմ, այն կարող է նորից փորձել միայն այն դեպքում, երբ հաղորդակցությունը ձախողվի: Նույնիսկ SOAP միջանկյալ նյութեր օգտագործելիս SOAP-ն առաջարկում է վերջնական հուսալիություն՝ շնորհիվ իր ներկառուցված հաջող/կրկնակի տրամաբանության:
- SOAP-ն արդեն համապատասխանում է ACID ստանդարտներին: Թելադրելով, թե ինչպես կարող են գործարքները փոխազդել տվյալների բազայի հետ՝ ACID-ի համապատասխանությունը նվազագույնի է հասցնում անոմալիաները և պաշտպանում տվյալների բազայի հետևողականությունը: Քանի որ ACID-ն ավելի զգույշ է, քան տվյալների համահունչ այլ մոդելները, այն հաճախ օգտագործվում է զգայուն գործարքները կառավարելիս՝ ֆինանսական կամ այլ կերպ:
- Ծրագրավորողների համար դա պարզ է հասկանալ, քանի որ SOAP-ը լիովին XML-ի վրա հիմնված հաղորդակցություն է:
- XML հաղորդագրությունների արձանագրությունը HTTP արձանագրության հավելումն է:
- Հաղորդակցությունները մի համակարգչից մյուս համակարգիչ կարող են տարածվել SOAP հաղորդագրությունների միջոցով:
- Հաճախորդ-սերվերի ճարտարապետությունը նույնպես կարող է իրականացվել: SOAP պրոտոկոլային հաղորդագրությունը կարող է օգտագործվել հաճախորդի կողմից՝ սերվերի կողմում գտնվող հեռավոր ընթացակարգային զանգ կանչելու համար:
ՀԱՆԳՍՏԻ ընդդեմ օճառի տարբերությունները
1: ճարտարապետություն
API-ը նախատեսված է հիմնականում սերվերի վրա հավելվածի բիզնես տրամաբանության հատուկ բաղադրիչներ ցուցադրելու համար: Մինչ REST-ն օգտագործում է URI-ներ նույն նպատակով, SOAP-ն օգտագործում է ծառայության ինտերֆեյս դրա համար:
REST API-ները ստեղծվում են տվյալներից հետո, մինչդեռ SOAP API-ները մշակվում են այն գործառույթներից հետո, որոնք ցուցադրում է API-ն: Համեմատած SOAP-ի հետ, որն ավելի շատ գործառույթների վրա է հիմնված, REST-ը ավելի շատ տվյալների վրա հիմնված դիզայն է:
2. Caching
Տվյալները, որոնք նշվել են որպես cacheable, կարող են կրկին օգտագործվել բրաուզերների կողմից՝ չպահանջելով, որ նրանք նոր հարցում կատարեն սերվերին: Ժամանակի և ջանք խնայելը սրա օգուտն է:
Պատասխանները չեն պահվի HTTP մակարդակում, քանի որ SOAP հարցումները ներկայացվում են POST հարցումների միջոցով, որոնք HTTP ստանդարտը համարում է ոչ անիմաստ: Եթե ցանկանում եք օգտագործել քեշավորումը, դուք դեռ պետք է ստեղծեք անհրաժեշտ տեխնիկան, քանի որ REST API-ները չեն ներառում այս իրականացումը:
3. Ռեսուրսներ և թողունակություն
Շնորհիվ SOAP-ի կողմից օգտագործվող ծրարային եղանակով օգտակար բեռների փոխանցման, վերադիր ծախսերի համեստ աճ կա, ինչը պահանջում է լրացուցիչ թողունակություն: REST-ի թեթև բնույթը օգուտ է այս իրավիճակներում, քանի որ այն սովորաբար օգտագործվում է վեբ ծառայությունների համար:
4. Անվտանգություն
WS-անվտանգությունը, որն աջակցում է SOAP-ին և մի փոքր ավելի մանրակրկիտ է, քան SSL-ը տրանսպորտային մակարդակում, ցանկալի է: Դրա հետ ձեռնարկության մակարդակի անվտանգության միջոցների ներդրումը նույնպես կատարյալ տեղավորվում է:
SSL-ի միջոցով ծայրից ծայր կոդավորումը աջակցվում է և՛ SOAP-ի, և՛ REST-ի կողմից, և REST-ը կարող է օգտագործել HTTPS՝ HTTP արձանագրության անվտանգ տարբերակը:
5. Բեռնափոխադրումներ
Ինտերնետի միջոցով փոխանցվող տվյալները կոչվում են օգտակար բեռ: «Ծանր» համարվող ծանրաբեռնվածությունը լրացուցիչ ռեսուրսների կարիք ունի: Համեմատած SOAP-ի հետ, որն օգտագործում է XML, REST-ը հաճախ օգտագործում է JSON և HTTP՝ օգնելու նվազեցնել ծանրաբեռնվածությունը:
Հաճախորդի կողմից ստեղծված կոդով մասնագիտացված գրադարանը սովորաբար պետք է օգտագործվի Հաճախորդի կողմից SOAP API-ներ մուտք գործելու համար՝ կապված նրանց չափազանց խիստ կապի պայմանագրի պատճառով:
Արդյունքում, SOAP-ն առաջարկում է աբստրակցիայի ավելի քիչ մակարդակ, քան REST-ը և ավելի սերտորեն կապված է սերվերի հետ։
Ե՞րբ օգտագործել REST-ը:
- Հանրային API-ների ստեղծումREST API-ները նախընտրելի են հանրային վեբ ծառայությունների ստեղծման համար, քանի որ դրանք ավելի պարզ են օգտագործման և ընդունման համար, քան SOAP API-ները: Բացի այդ, SOAP-ն առաջարկում է մի քանի ներկառուցված անվտանգության միջոցներ, որոնք REST-ը չունի, թեև այդ բնութագրերը պարտադիր չեն բաց տվյալների և ծառայությունների հետ աշխատելիս:
- Բջջային հավելվածների կառուցումREST-ը կատարյալ է բջջային հավելվածներ ստեղծելու համար, քանի որ այն փոքր է, արդյունավետ, քաղաքացիություն չունեցող և քեշի ենթակա:
- Օգտագործելով սակավ սերվերի ռեսուրսները և թողունակությունըREST API-ի բոլոր հարցումները պետք է լինեն քաղաքացիություն չունեցող, ինչը նշանակում է, որ յուրաքանչյուր փոխազդեցություն առանձին է, և յուրաքանչյուր հարցում և պատասխան պարունակում է բոլոր տվյալները, որոնք անհրաժեշտ են այդ փոխազդեցությունն ավարտելու համար: Սերվերը չի պահպանում նախորդ հարցումների գրառումները, քանի որ յուրաքանչյուրը վերաբերվում է որպես թարմ հարցում: Արդյունքում, սերվերը պահանջում է շատ ավելի քիչ հիշողություն և ավելի արագ է գործում, քանի որ հարցումը չի պահանջում հետագա գործողությունների կամ պատմական տվյալների որոնման անհրաժեշտություն:
Ե՞րբ օգտագործել SOAP-ը:
- Մասնավոր API-ների ստեղծում, հատկապես խոշոր բիզնեսների համարSOAP-ը կատարյալ է կորպորատիվ ծրագրերի համար, քանի որ այն հնարավորություն է տալիս տվյալների հոսքը ապակենտրոնացված, բաշխված միջավայրում և պարունակում է մի քանի առցանց անվտանգության առանձնահատկություններ:
- Օգտագործելով HTTP-ից այլ տրանսպորտային արձանագրություն՝ որպես հիմքում ընկած շերտSOAP-ը կախված չէ HTTP-ից՝ որպես հիմքում ընկած շերտ: Կախված ձեր դիմումից, դուք կարող եք օգտագործել SMTP (Simple Mail Transfer Protocol), JMS (Java Messaging Service) կամ այլ տրանսպորտային արձանագրություն:
- Աշխատեք պետական գործառնությունների հետԻ տարբերություն REST API-ների հարցումների, SOAP API-ների հարցումները պետական են, այսինքն՝ սերվերը պահպանում է հաճախորդի մասին տեղեկատվությունը և օգտագործում այն հարցումների կամ գործողությունների շղթայում: Նույնիսկ եթե սա օգտագործում է ավելի շատ սերվերի թողունակություն և ռեսուրսներ, այն կարևոր է սովորական կամ կապված գործողություններ իրականացնելու համար, ինչպիսիք են բանկային փոխանցումները:
Եզրափակում
REST-ի և SOAP API-ների համեմատությունը միանգամայն ակնհայտ է դարձնում, որ REST-ը նախընտրելի է SOAP-ից: Նույնիսկ դեռ, կան իրավիճակներ, երբ SOAP API-ն պահանջվում է: Որոշ դեպքերում վեբ ծառայությունները ստեղծվում են REST և SOAP API-ների համատեղմամբ:
Հետևաբար, օգտագործման դեպքը կորոշի, թե որ API ոճն է լավագույնս աշխատելու:
Թողնել գրառում