Что такое 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