Що таке 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 відрізняється від API будь-якого іншого віддаленого сервера?

У технічному плані різниця полягає у форматі запиту та відповіді.

Щоб відобразити всю веб-сторінку, ваш браузер очікує відповіді в HTML, який містить презентаційний код, тоді як дзвінок API Календаря Google просто поверне дані - ймовірно, у форматі, подібному до 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 готова до використання у вашому коді. Витягти дані з цього тексту легко. Тоді ви можете робити з даними все, що завгодно.

A - це "Застосування"

Щоб закрити, давайте додамо ще пару прикладів 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