რა არის API? - მარტივად ახსნილი დამწყებებისთვის

მსოფლიო ქსელი და დისტანციური სერვერები

WWW შესაძლებელია წარმოვიდგინოთ, როგორც დაკავშირებული ქსელების მსხვილი ქსელი, სადაც ყოველი გვერდი ინახება. ჩვეულებრივი ნოუთბუქი შეიძლება გადაიქცეს სერვერად, რომელიც ქსელში მთელ საიტს მოემსახურება, ხოლო ლოკალურ სერვერებს დეველოპერები იყენებენ საიტის შესაქმნელად, სანამ მომხმარებელთა ფართო სპექტრისთვის გახსნიან.

ბრაუზერის მისამართის ზოლში www.facebook.com-ის ჩაწერისას Facebook-ის დისტანციურ სერვერზე შესაბამისი მოთხოვნა იგზავნება. როგორც კი ბრაუზერი პასუხს იღებს, კოდის ინტერპრეტაციას ახდენს და მას საიტზე ასახავს. 

ყოველ ჯერზე, როდესაც მომხმარებელი ქსელში რომელიმე გვერდს ეწვევა, ის API-ს დისტანციურ სერვერთან ურთიერთქმედებაში შედის. API — სერვერის ნაწილია, რომელიც იღებს მოთხოვნებს და აგზავნის პასუხებს. 

API, როგორც კლიენტების მომსახურების საშუალება

ბევრი კომპანია გვთავაზობს API-ს, როგორც მზა პროდუქტს. მაგალითად, Weather Underground ყიდის ხელმისაწვდომობას საკუთარ API-ზე მეტეოროლოგიური მონაცემების მისაღებად. 

გამოყენების სცენარი: მცირე კომპანიის საიტზე მიღებაზე კლიენტების ჩასაწერად არსებობს ფორმა. კომპანიას სურს, რომ იქ  Google Calendar ჩააშენოს, რათა კლიენტებს საშუალება მისცეს, ავტომატურად შექმნან მოვლენა (event) და მომავალ შეხვედრაზე დეტალები შეიტანონ. 

API-ს გამოყენება: მიზანი — საიტის სერვერი პირდაპირ უნდა დაუკავშირდეს Google-ის სერვერს მოთხოვნით, რათა შეიქმნას მოვლენა (event) მითითებული დეტალებით, მან უნდა მიიღოს პასუხი Google-სგან, დაამუშაოს და შესაბამისი ინფორმაცია გადასცეს ბრაუზერში. მაგალითად, დადასტურების შეტყობინება. 

ალტერნატივის სახით, ბრაუზერმა შეიძლება მოთხოვნა გააგზავნოს Google-ის სერვერის API-სთან, კომპანიის სერვერის გვერდის ავლით. 

რით განსხვავდება Google Calendar-ის API ქსელში ნებისმიერი სხვა დისტანციური სერვერის API-სგან?

ტექნიკურად, სხვაობა მოთხოვნის ფორმატსა და პასუხშია. მთლიანი ვებგვერდის გენერირებისთვის, ბრაუზერი ელოდება პასუხს HTML-ის ენაზე, იმ დროს, როცა Google კალენდრის API დააბრუნებს მონაცემებს JSON-ის ფორმატში. 

თუ API-ზე მოთხოვნა ხდება კომპანიის ვებსაიტის სერვერის მიერ, მაშინ ის არის კლიენტი (ისევე, როგორც ვებსაიტის გახსნისას, კლიენტი ბრაუზერი არის)

თანამედროვე საიტების უმრავლესობა, სულ მცირე, რამდენიმე გარე API-ს იყენებს. ბევრ ამოცანას უკვე აქვს მზა გადაწყვეტილებები, რომლებსაც მესამე მხარის დევოლეპერები სთავაზობენ, იქნება ეს ბიბლიოთეკა თუ მომსახურება. ხშირად უფრო ადვილი და საიმედოა მზა გადაწყვეტის გამოყენება.

ბევრი დეველოპერი აპლიკაციას რამდენიმე სერვერზე ანაწილებს, რომლებიც ერთმანეთს API-თ უკავშირდებიან. სერვერებს, რომლებიც აპლიკაციის მთავარ სერვერთან მიმართებით დამხმარე ფუნქციას ასრულებენ, მიკროსერვერებს უწოდებენ. 

ამრიგად, როდესაც კომპანია მომხმარებლებს თავის API-ს სთავაზობს, ეს უბრალოდ ნიშნავს, რომ მან რამდენიმე სპეციალური URL შექმნა, რომლებიც პასუხად მხოლოდ მონაცემებს აგზავნიან. 

მსგავსი მოთხოვნების გაგზავნა ბრაუზერიდან შეიძლება. ვინაიდან მონაცემების გადაცემა HTTP-ის პროტოკოლით მხოლოდ ტექსტური სახით ხდება, ბრაუზერი ყოველთვის შეძლებს პასუხის ასახვას. მაგალითად, ბრაუზერიდან პირდაპირ შეიძლება GitHub-ის API-სთვის მიმართვა და JSON-ის ფორმატში, აი, ასეთი პასუხის მიღება:

ბრაუზერი შესანიშნავად ასახავს JSON-ის პასუხს, რომელიც თავისუფლად შეიძლება კოდში ჩაისვას. ასეთი ტექსტიდან საკმაოდ მარტივია მონაცემების ამოღება, საკუთარი შეხედულებისამებრ გამოყენებისთვის. 

API-ს კიდევ რამდენიმე მაგალითი

სიტყვა «application» შესაძლებელია სხვადასხვა მნიშვნელობით იქნას გამოყენებული. API-ს კონტექსტში ის გულისხმობს:

• პროგრამული უზრუნველყოფის ფრაგმენტი გარკვეული ფუნქციით,
• მთლიანად სერვერი, მთლიანად აპლიკაცია ან უბრალოდ აპლიკაციის ცალკეული ნაწილი. 

პროგრამული უზრუნველყოფის ნებისმიერ ფრაგმენტს, რომელიც მკაფიოდ  გამოირჩევა გარემოსგან, ინგლისურენოვან აბრევიატურაში შეუძლია ასო «A-ს» ჩანაცვლება და, ასევე, შეუძლია გარკევული სახის API ჰქონდეს. მაგალითად, სხვისი ბიბლიოთეკის კოდში დეველოპერის შეღწევით, ის მთლიანი აპლიკაციის ნაწილი ხდება. როგორც პროგრამული უზრუნველყოფის დამოუკიდებელი ნაწილი, მას ექნება რაღაც API, რომელიც საშუალებას მისცემს ურთიერთქმედებაში შევიდეს აპლიკაციის დანარჩენ კოდთან. 

ობიექტზე ორიენტირებულ პროგრამირებაში კოდი ობიექტების ერთობლიობაა. აპლიკაციაში შეიძლება იყოს ასობით ასეთი ობიექტი, რომლებიც ურთიერთქმედებენ ერთმანეთთან. ყველა მათგანს აქვს საკუთარი API — საჯარო თვისებებისა და მეთოდების ნაკრები აპლიკაციაში სხვა ობიექტებთან ურთიერთქმედებისთვის. ობიექტებს ასევე შესაძლოა ჰქონდეთ პირადი, შიდა ლოგიკა, რომელიც დამალულია გარემოსგან და არ არის API.