Что такое API?
Я видел в Интернете вопросы о людях, которые спрашивали «что такое API»?
Должен признаться, я сначала был весьма удивлен, увидев такой вопрос. Я так долго работал и думал об API, что это стало частью моей работы. Я даже упустил из виду, что люди могут не много об этом знать.
Я понял, почему это так очевидно для меня. Концепция API везде и всегда. Я так много раз в день спрашиваю себя об API, своих или других. Я живу API.
И вы тоже. В настоящее время наша работа как инженеров заключается в том, чтобы иметь дело с абстракциями поверх абстракций, будь то языки, инструменты, фреймворки или плагины. Мы всегда находимся перед некоторыми API.
И я считаю, что понимание этого - важная часть нашей работы.
Реализация и интерфейсы
Знаете ли вы шаблоны проектирования, элементы объектно-ориентированного программного обеспечения многократного использования? Известны как шаблоны дизайна GoF.
Эти шаблоны буквально диктуют, как мы создаем программное обеспечение, и это делается с 1994 года.
Сегодня ничего не изменилось. Всегда те заводы, одиночки, строители, наблюдатели. Это говорит о том, насколько они сильны.
Они делают акцент на двух основных правилах программирования:
- Программа для интерфейса, а не реализация
- Предпочитайте композицию объекта наследованию класса
Гуру Javascript любят второй (привет, Эрик Эллиот!). Нас больше интересует первый.
Когда вы пишете код, вы обычно разделяете свою кодовую базу на более мелкие функции, которые представляют собой отдельные блоки, выполняющие одно действие. Например, функция createUser может создать объект пользователя.
Функция состоит из двух частей:
- Интерфейс: это сигнатура функции. Он содержит имя, принимаемые параметры, их тип и возвращаемое значение.
- Реализация: это код внутри вашей функции.
Это верно для классов: имена методов - это интерфейс, код внутри него - это реализация.
Это всегда вопрос разделения интерфейса и реализации.
Причина, по которой мы это делаем, заключается в том, что мы хотим рассуждать в терминах интерфейсов, потому что нам удобнее давать семантическое значение функции (функция createUser создает пользователя), а не сканировать ее код. чтобы понять, о чем идет речь.
Работа с интерфейсами - это то, что позволяет нам сосредоточиться на нашей проблеме. Мы знаем, что функция createUser создаст пользователя. Если эта функция не работает, вы знаете, что нужно исправить, и вы избавитесь от всего контекста, который ее окружает.
Обсуждение в терминах интерфейса также позволяет вам создать функцию, которая будет выполнять именно то, что вы от них хотите, если вы знаете ввод и вывод.
Когда я мысленно представляю свой код, когда мне нужно создать функцию, первое, что мне приходит в голову, это:
- Какое имя точно скажет, что функция должна делать?
- Какие доступные входы мне понадобятся для передачи функции, когда я ее вызову?
- Какой результат я ожидаю?
Как только мой интерфейс настроен, я могу его закодировать: это может быть реальная реализация, или он может просто возвращать поддельные данные, все, что мне нужно в данный момент. Я могу написать мусорный код и при необходимости реорганизовать его позже. Изоляция обеспечивает мне безопасность, стабильность и сохраняет легкость моей ментальной модели.
Экспозиция
После того, как моя функция настроена, я должен открыть ее, чтобы внешний мир получил к ней доступ.
Экспозиция - это просто термин, означающий, что ваша функция может быть вызвана извне. Например, если вы разрабатываете метод для своего класса, его раскрытие состоит в том, чтобы сделать его общедоступным, чтобы потребитель, который создаст экземпляр вашего класса, мог вызвать эту функцию.
Теперь на каком-то языке, таком как Javascript, у вас есть модули. Функции, определенные внутри модуля, являются локальными для этого модуля и не могут быть вызваны извне, если они не экспортированы. Когда вы экспортируете функцию, вы открываете ее.
И здесь все обретает смысл в API.
API - это открытые интерфейсы.
Ага. Это все. Больше нечего знать. Это правда, которую вы ждали.
Звучит дешево, но на самом деле эта концепция очень мощная. Потому что API - это то, что отделяет интерфейс от его реализации.
Это причина того, что компьютер такой мощный.
Возьмем пример: вы пользуетесь API Twitter и хотите получать твиты. В первый день вы получаете твиты, используя URI https://api.twitter.com/tweets (конечно, фиктивный URI).
Вы не представляете, что происходит на серверах Twitter. Вы не знаете, какая функция вызывается, что она делает. Вы не знаете языка API. Вы не знаете, какую базу данных он использует (вы даже не знаете, используют ли они базу данных). Вы понятия не имеете, отлаживает ли какой-нибудь ниндзя Твиттера вызовы API.
Вы знаете только, что эта функция возвращает чертовы твиты.
Что, если однажды твиттер переключится с MySQL на MongoDB?
И переключится с использования БД на ElasticSearch для своих твитов?
И поместит свою логику получения твитов в микросервис?
И контролировать весь их API с помощью какого-либо сервиса AWS?
Или получить твиты из какой-то БД в памяти?
Или AB тестирует от вашего имени?
Что, если они переключат API с .NET на NodeJS?
Вы не знаете, вы никогда не узнаете.
А главное, вам все равно.
Это потому, что интерфейс очень мощный. В нем говорится: «Это то, что вы можете мне дать, и это то, что вы можете ожидать от меня».
Внутренняя логика - это деталь реализации.
Интерфейс определяет контракт, который никогда и никогда не должен разорваться. Этот контракт гарантирует клиентам, что API будет работать должным образом, независимо от изменений, происходящих внутри реализации.
И действительно, эта концепция настолько сильна. Поскольку вы можете изменять свою функцию по своему усмотрению, это никогда не сломает ваш код.
Вот почему я всегда думаю об API. Хорошее программное обеспечение, написанное с помощью API правильной формы, - одно из лучших лекарств от регресса.
Самое важное правило API, которое Роберт Мартин назвал принципом открытия / закрытия.
Функция должна быть открыта для расширения, но закрыта для модификации.
Его можно улучшать, добавлять функции, развиваться, но он не может изменить свой интерфейс, свой контракт.
Заключение
API везде. В разработке программного обеспечения он отделяет интерфейс от реализации. В повседневной жизни это проявляется по-другому.
Например, официант - это интерфейс, предоставляемый рестораном. Он предоставляет простой API для получения вашего обеда. Он спрашивает вас, что вы хотите, называет цены, показывает, что есть в наличии, и заботится о том, чтобы отметить это, передать его повару, забрать это с кухни и принести вам.
Когда вы снимаете деньги, автомат предоставляет API. Вы вводите частный код своей карты, запрашиваете деньги, и он делает тяжелую работу по хранению операции и снятию ваших денег.
То же самое и с вычислениями. У вас есть API на аппаратном уровне, на уровне программного обеспечения, в сети, везде.
Twitter позволяет вам работать с твитами, используя их удаленный API.
Но он также предоставляет вам SDK с API для каждого языка, который использует удаленный API.
Он использует HTTP, который также предоставляет API.
HTTP использует TCP, который предоставляет API (с сокетами и портами).
Этот TCP будет использовать протокол IP, который предоставляет API.
Протокол IP с использованием любых данных -layer.
Уровень данных будет связываться с вашей сетевой картой, которая предоставляет аппаратный API.
И так далее, и так далее.
Блин, это так глубоко.
Надеюсь, вам понравилась эта небольшая статья об API. Я взял мотивацию написать это после просмотра видео в Instagram.
Не стесняйтесь задавать вопросы и нажимайте кнопку "Нравится".
Я также хотел бы, чтобы вы подписались на меня, чтобы получать уведомления, когда я пишу такой (допинг) контент!
