გსურთ დააკავშიროთ თქვენი აპი ფეისბუკს, რათა მან ავტომატურად შექმნას პოსტები, ან ინსტაგრამზე, რათა ხელახლა გამოაქვეყნოთ ფოტოები გარკვეული ჰეშთეგებით?
თქვენ ასევე შეგიძლიათ გსურთ YouTube-ის ვიდეოების ჩართვა თქვენს ვებსაიტზე. აპლიკაციის პროგრამირების ინტერფეისები საშუალებას გაძლევთ შეასრულოთ ყველა ეს ამოცანა და მეტი (API).
სხვადასხვა აპლიკაციებს შეუძლიათ უსაფრთხოდ და სტანდარტიზებული სახით „ელაპარაკეთ“ ერთმანეთს API-ების წყალობით, როგორიცაა Instagram API, Facebook API და YouTube API.
სხვა სიტყვებით რომ ვთქვათ, პროგრამას შეუძლია მიიღოს ფუნქციები ან მონაცემები პროგრამული უზრუნველყოფის სხვა ნაწილიდან და გამოიყენოს ისინი საკუთარი მახასიათებლების ან მომხმარებლის გამოცდილების გასაუმჯობესებლად. მაგრამ როგორ შეუძლიათ აპებს ამ მოთხოვნების გაკეთება, დამუშავება და სხვებისთვის გასაგებად რეაგირება?
ეს დამოკიდებულია იმაზე, თუ როგორ შეიქმნა API. API (აპლიკაციის პროგრამირების ინტერფეისის) დიზაინის განხილვისას, ჩვეულებრივ უნდა შევადაროთ SOAP და REST, ორი ყველაზე ცნობილი API პარადიგმა.
როგორც კი SOAP APIs (Simple Object Access Protocol) გახდა ოქროს სტანდარტი ფირმებისთვის, როგორიცაა Oracle, Sun და PayPal, ერთი წლის შემდეგ იყო თანაბარი და საპირისპირო პასუხი Google-ის, Amazon-ისა და eBay-ის REST API-ების მიმართ.
ამ პოსტში ჩვენ შევადარებთ და დავაპირისპირებთ SOAP API-ებს REST API-ებთან, რათა გადაწყვიტოთ რომელია საუკეთესო თქვენი მიზნებისთვის.
ჩვენ დავიწყებთ API-ს განსაზღვრით.
რა არის API?
აპლიკაციის პროგრამირების ინტერფეისი მოიხსენიება როგორც API. API არსებითად არის მეთოდებისა და ფუნქციების კრებული, რომელიც საშუალებას აძლევს აპების შემუშავებას. ისინი იღებენ წვდომას სხვადასხვა პროგრამების, სერვისების ან ოპერაციული სისტემების ინფორმაციაზე და ფუნქციებზე.
ისინი ემსახურებიან როგორც შუამავალს სხვადასხვა პროგრამულ სისტემებს შორის. ისინი აძლევენ „საუბარს“ ორ უკავშირო პროგრამას შორის.
ავიღოთ საფონდო ბროკერის მაგალითი, რომელიც აქტიურად არის ჩართული ვაჭრობაში და ფინანსურ ბაზრებზე. ავტომატური კოლექცია სავაჭრო ალგორითმები შეიძლება დაუკავშირდეს ტრეიდერის საყვარელ სავაჭრო ბროკერის პლატფორმას API-ის საშუალებით. ეს საშუალებას გაძლევთ, ტრეიდერს, განახორციელოთ ელექტრონული ტრანზაქციები ან ნახოთ რეალურ დროში შეთავაზებები და ფასების მონაცემები.
რა არის REST?
ჭეშმარიტი „ვებ სერვისების“ API მოიცავს REST (წარმომადგენლობითი სახელმწიფო გადაცემა). REST API-ები აგებულია URI-ებზე (რესურსების ერთიანი იდენტიფიკატორები, რომელთაგან URL არის განსაკუთრებული სახეობა), HTTP პროტოკოლსა და ბრაუზერთან წარმოუდგენლად თავსებადი JSON მონაცემთა ფორმატზე.
SOAP პროტოკოლი, როგორც უკვე აღვნიშნეთ, შესაძლოა ასევე იყოს გამოყენებული. REST API-ების შექმნა და ზრდა შეიძლება მარტივი იყოს, მაგრამ ისინი ასევე შეიძლება იყოს უზარმაზარი და რთული - ეს ყველაფერი დამოკიდებულია იმაზე, თუ როგორ იქმნება, გაფართოვდება და რის გაკეთებას აპირებენ.
რესურსების შეზღუდვა, უსაფრთხოების შემცირებული მოთხოვნები, ბრაუზერის კლიენტის თავსებადობა, აღმოჩენადობა, მონაცემთა სიჯანსაღე და მასშტაბურობა არის რამდენიმე მიზეზი, რის გამოც გსურთ განავითაროთ API, რომ იყოს RESTful - ის, რაც რეალურად ეხება ვებ სერვისებს.
REST გთავაზობთ უფრო მსუბუქ ვარიანტს. SOAP რთული გამოსაყენებელი და მძიმე იყო მრავალი დეველოპერისთვის. მაგალითად, SOAP-ის გამოყენება JavaScript-ით მოითხოვს ბევრი კოდის დაწერას მარტივი ოპერაციების დასასრულებლად, რადგან საჭირო XML სტრუქტურა უნდა შეიქმნას ყოველ ჯერზე.
REST (ჩვეულებრივ) იყენებს პირდაპირ URL-ს XML მოთხოვნის ნაცვლად. მიუხედავად იმისა, რომ არის იშვიათი გარემოებები, როდესაც თქვენ უნდა შემოგთავაზოთ მეტი დეტალი, RESTful ვებ სერვისების უმეტესობა იყენებს მხოლოდ URL ტექნიკას.
ოთხი HTTP 1.1 ზმნა GET, POST, PUT და DELETE შეიძლება გამოყენებულ იქნას REST-ის მიერ ოპერაციების განსახორციელებლად. SOAP-ისგან განსხვავებით, REST-ს არ სჭირდება პასუხი XML-ში იყოს.
ხელმისაწვდომია REST-ზე დაფუძნებული ვებ სერვისები, რომლებიც აწარმოებენ მონაცემებს Command Separated Value (CSV), JavaScript Object Notation (JSON) და Really Simple Syndication (RSS) ფორმატებში (RSS).
მიზანი არის ის, რომ თქვენ შეგიძლიათ მიიღოთ თქვენთვის საჭირო შედეგები ადვილად გასარჩევი ფორმატით იმ ენაში, რომელსაც იყენებთ თქვენი განაცხადისთვის.
მისი მახასიათებლებია;
- REST ხაზს უსვამს სიმარტივეს უპირველეს ყოვლისა, HTTP პროტოკოლების გამო.
- ვებ საუკეთესოდ შეეფერება REST-ს. ის თავსებადია ბრაუზერებთან, რადგან JSON გამოიყენება როგორც მონაცემთა ფორმატი.
- REST ცნობილია თავისი გამორჩეული მასშტაბურობითა და სიჩქარით.
- კლიენტ-სერვერის კავშირები და არქიტექტურები უფრო ხელმისაწვდომი ხდება REST API-ებით. თუ ეს არის RESTful, ის აგებულია კლიენტ-სერვერის მოდელის გამოყენებით, ორ მხარეს შორის ორმხრივი მოგზაურობით, რომლებიც გადადიან მონაცემთა დატვირთვით.
- REST API-ები იყენებენ ცალკეულ სტანდარტულ ინტერფეისს. იმის უზრუნველყოფა, რომ ყველა აპი ერთნაირად და ერთი და იგივე კარიბჭის მეშვეობით არის დაკავშირებული, აუმჯობესებს აპლიკაციების კომუნიკაციას API-სთან.
რა არის საპონი?
მისი საკუთარი პროტოკოლი, სახელწოდებით 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 შეტყობინებები უკეთ ფუნქციონირებს.
მისი მახასიათებლებია;
- საპნის უსაფრთხოება საგრძნობლად მკაცრდება. WS-Security არის ჩაშენებული სტანდარტი, რომელიც გთავაზობთ SOAP-ის დამატებით საწარმოს დონის უსაფრთხოების შესაძლებლობებს, საჭიროების შემთხვევაში, SSL მხარდაჭერის გარდა.
- წარმატებული/ხელახლა მსჯელობა შეტყობინებების სანდო შესრულებისთვის. იმის გამო, რომ REST-ს არ გააჩნია შეტყობინების სტანდარტიზებული მექანიზმი, მას შეუძლია ხელახლა ცდა მხოლოდ მაშინ, როდესაც კომუნიკაცია ვერ ხერხდება. მაშინაც კი, როდესაც SOAP შუალედებს იყენებთ, SOAP გთავაზობთ ბოლომდე საიმედოობას მისი ჩაშენებული წარმატებული/განმეორებითი ლოგიკის გამო.
- SOAP უკვე შეესაბამება ACID სტანდარტებს. კარნახით, თუ როგორ შეიძლება ტრანზაქციებმა შეძლოს მონაცემთა ბაზასთან ურთიერთქმედება, ACID შესაბამისობა ამცირებს ანომალიებს და იცავს მონაცემთა ბაზის თანმიმდევრულობას. იმის გამო, რომ ACID უფრო ფრთხილია, ვიდრე სხვა მონაცემთა თანმიმდევრულობის მოდელები, ის ხშირად გამოიყენება სენსიტიური ტრანზაქციების მართვისას, ფინანსური თუ სხვა.
- პროგრამისტებისთვის ამის გაგება მარტივია, რადგან SOAP არის მთლიანად XML-ზე დაფუძნებული კომუნიკაცია.
- XML შეტყობინებების პროტოკოლი არის HTTP პროტოკოლის დამატება.
- კომუნიკაციები ერთი კომპიუტერიდან მეორე კომპიუტერზე შეიძლება გავრცელდეს SOAP შეტყობინებების საშუალებით.
- კლიენტ-სერვერის არქიტექტურა ასევე შეიძლება განხორციელდეს. SOAP პროტოკოლის შეტყობინება შეიძლება გამოიყენოს კლიენტმა დისტანციური პროცედურის ზარის გამოსაძახებლად, რომელიც მდებარეობს სერვერის მხარეს.
REST vs SOAP განსხვავებები
1. არქიტექტურა
API განკუთვნილია სერვერზე აპლიკაციის ბიზნეს ლოგიკის სპეციფიკური კომპონენტების ჩვენებისთვის. მიუხედავად იმისა, რომ REST იყენებს URI-ებს იმავე მიზნით, SOAP იყენებს სერვისის ინტერფეისს ამისთვის.
REST API-ები იქმნება მონაცემების შემდეგ, ხოლო SOAP API-ები იქმნება იმ ფუნქციონალების მიხედვით, რომლებსაც API ასახავს. SOAP-თან შედარებით, რომელიც უფრო ფუნქციებზეა ორიენტირებული, REST უფრო მონაცემთა დიზაინია.
2. ქეშირება
მონაცემები, რომლებიც მონიშნულია როგორც ქეშირებადი, ბრაუზერებმა შეიძლება კვლავ გამოიყენონ სერვერზე ახალი მოთხოვნის გარეშე. დროისა და ძალისხმევის დაზოგვა ამის სარგებელია.
პასუხები არ შეინახება 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-ს ყველა მოთხოვნა უნდა იყოს მოქალაქეობის არმქონე, რაც ნიშნავს, რომ თითოეული ურთიერთქმედება ცალკეა და თითოეული მოთხოვნა და პასუხი შეიცავს ყველა მონაცემს, რომელიც აუცილებელია ამ ურთიერთქმედების დასასრულებლად. სერვერი არ ინახავს წინა მოთხოვნების ჩანაწერებს, რადგან ის განიხილავს თითოეულ მათგანს, როგორც ახალ მოთხოვნას. შედეგად, სერვერს გაცილებით ნაკლები მეხსიერება სჭირდება და უფრო სწრაფად მუშაობს, რადგან მოთხოვნა არ საჭიროებს შემდგომ მოქმედებას ან ისტორიული მონაცემების მოძიებას.
როდის გამოვიყენოთ საპონი?
- კერძო 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 სტილი იმუშავებს საუკეთესოდ.
დატოვე პასუხი