Какво е API? На английски моля.

Преди да науча разработката на софтуер, API звучеше като нещо като бира.

Днес използвам термина толкова често, че всъщност наскоро се опитах да поръчам API на бар.

Отговорът на бармана беше да хвърли 404: ресурс не беше намерен.

Срещам много хора, работещи в сферата на технологиите и другаде, които имат доста неясна или неправилна представа за това какво означава този доста често срещан термин.

Технически, API означава интерфейс за програмиране на приложения . В един или друг момент повечето големи компании са изградили API за своите клиенти или за вътрешна употреба.

Но как да обясните API на обикновен английски? И има ли по-широк смисъл от този, използван в развитието и бизнеса? Първо, нека се отдръпнем и да разгледаме как работи самата мрежа.

WWW и отдалечени сървъри

Когато мисля за мрежата, си представям голяма мрежа от свързани сървъри.

Всяка страница в интернет се съхранява някъде на отдалечен сървър. Все пак отдалеченият сървър не е толкова мистичен - той е само част от отдалечен компютър, който е оптимизиран за обработка на заявки.

За да поставите нещата в перспектива, можете да завъртите сървър на вашия лаптоп, способен да обслужва цял уебсайт в мрежата (всъщност локалният сървър е това, което инженерите използват, за да разработват уебсайтове, преди да ги пуснат публично).

Когато въведете www.facebook.com в браузъра си, заявка излиза към отдалечения сървър на Facebook. След като браузърът ви получи отговора, той интерпретира кода и показва страницата.

За браузъра, известен също като клиент , сървърът на Facebook е API. Това означава, че всеки път, когато посещавате страница в мрежата, вие взаимодействате с API на някой отдалечен сървър.

API не е същото като отдалечения сървър - по-скоро е частта от сървъра, която получава заявки и изпраща отговори .

API като начин за обслужване на вашите клиенти

Вероятно сте чували за компании, които опаковат API като продукти. Например Weather Underground продава достъп до своя API за данни за времето.

Примерен сценарий: Уебсайтът на вашия малък бизнес има формуляр, използван за регистриране на клиенти за срещи. Искате да дадете на клиентите си възможността автоматично да създават събитие в календара на Google с подробности за тази среща.

Използване на API: Идеята е сървърът на вашия уебсайт да говори директно със сървъра на Google с искане за създаване на събитие с дадените подробности. След това вашият сървър ще получи отговора на Google, ще го обработи и ще изпрати обратно съответната информация на браузъра, като съобщение за потвърждение до потребителя.

Алтернативно, вашият браузър често може да изпрати заявка за API директно до сървъра на Google, заобикаляйки вашия сървър.

Как се различава API на този Google Calendar от API на всеки друг отдалечен сървър там?

В техническо отношение разликата е във формата на заявката и отговора.

За да изобрази цялата уеб страница, браузърът ви очаква отговор в HTML, който съдържа презентационен код, докато извикването на API на Google Calendar просто ще върне данните - вероятно във формат като JSON .

Ако сървърът на вашия уебсайт прави заявка за API, тогава сървърът на вашия уеб сайт е клиентът (подобно на вашия браузър, който е клиент, когато го използвате за навигация до уебсайт).

От гледна точка на потребителите ви API позволяват да завършат действието, без да напускат уебсайта ви.

Повечето съвременни уебсайтове консумират поне някои API на трети страни.

Много проблеми вече имат решение на трета страна, било то под формата на библиотека или услуга. Често е по-лесно и по-надеждно да използвате съществуващо решение.

Не е необичайно екипите за разработки да разделят приложението си на множество сървъри, които говорят помежду си чрез API. Сървърите, които изпълняват помощни функции за основния сървър на приложения, обикновено се наричат микроуслуги .

За да обобщим, когато една компания предлага API на своите клиенти, това просто означава, че са изградили набор от специални URL адреси, които връщат чисти отговори на данни - което означава, че отговорите няма да съдържат вида на представяне, който бихте очаквали в графичен потребителски интерфейс като уебсайт .

Можете ли да направите тези заявки с вашия браузър? Често, да. Тъй като действителното HTTP предаване се случва в текст, вашият браузър винаги ще направи всичко възможно, за да покаже отговора.

Например можете да осъществите достъп до API на GitHub директно с вашия браузър, без дори да се нуждаете от маркер за достъп. Ето отговора на JSON, който получавате, когато посетите маршрута на API на потребителя на GitHub във вашия браузър (//api.github.com/users/petrgazarov):

{ "login": "petrgazarov", "id": 5581195, "avatar_url": "//avatars.githubusercontent.com/u/5581195?v=3", "gravatar_id": "", "url": "//api.github.com/users/petrgazarov", "html_url": "//github.com/petrgazarov", "followers_url": "//api.github.com/users/petrgazarov/followers", "following_url": "//api.github.com/users/petrgazarov/following{/other_user}", "gists_url": "//api.github.com/users/petrgazarov/gists{/gist_id}", "starred_url": "//api.github.com/users/petrgazarov/starred{/owner}{/repo}", "subscriptions_url": "//api.github.com/users/petrgazarov/subscriptions", "organizations_url": "//api.github.com/users/petrgazarov/orgs", "repos_url": "//api.github.com/users/petrgazarov/repos", "events_url": "//api.github.com/users/petrgazarov/events{/privacy}", "received_events_url": "//api.github.com/users/petrgazarov/received_events", "type": "User", "site_admin": false, "name": "Petr Gazarov", "company": "PolicyGenius", "blog": "//petrgazarov.com/", "location": "NYC", "email": "[email protected]", "hireable": null, "bio": null, "public_repos": 23, "public_gists": 0, "followers": 7, "following": 14, "created_at": "2013-10-01T00:33:23Z", "updated_at": "2016-08-02T05:44:01Z"}

Изглежда, че браузърът е направил отлично показване на JSON отговор. JSON отговор като този е готов за използване във вашия код. Извличането на данни от този текст е лесно. След това можете да правите каквото искате с данните.

А е за „Приложение“

За да затворим, нека да добавим още няколко примера за API.

„Приложение“ може да се отнася до много неща. Ето някои от тях в контекста на API:

  1. Софтуер с различна функция.
  2. Целият сървър, цялото приложение или само малка част от приложението.

По принцип всеки софтуер, който може да бъде отделен поотделно от заобикалящата го среда, може да бъде „A“ в API и вероятно също ще има някакъв API.

Да предположим, че използвате код на трета страна в кода си. След като бъде включена във вашия код, библиотеката става част от цялостното ви приложение. Като отделна част от софтуера, библиотеката вероятно ще има API, който й позволява да взаимодейства с останалата част от вашия код.

Ето още един пример: В обектно-ориентирания дизайн кодът е организиран в обекти. Вашето приложение може да има дефинирани стотици обекти, които могат да взаимодействат помежду си.

Всеки обект има API - набор от публични методи и свойства, които използва за взаимодействие с други обекти във вашето приложение.

An object may also have inner logic that is private, meaning that it’shiddenfrom the outside scope (and not an API).

From what we have covered, I hope you take away the broader meaning of API as well as the more common uses of the term today.

Interesting Resources (stuff that I left out but is still very cool):

A great youtube video on DNS (Domain Name System)

HTTP protocol basics

An Awesome Khan Academy video on Object Oriented Design Principles