API — это фундаментальная часть современного дизайна веб-приложений. Они позволяют вам получать доступ к сервисам множества разных компаний и источников через один веб-браузер. Многие люди взаимодействуют с API-интерфейсами и даже не осознают этого, например, с помощью кнопки «Войти через Facebook» на веб-сайте или в приложении, использующем вашу мобильную камеру.
Если вы хотите заняться разработкой веб-приложений, хорошее знание API необходимо для получения должности разработчика. Сегодня мы поможем вам начать работу с API, изучив, что такое API и какие типы вы увидите в современной среде разработки.
Что такое API?
API расшифровывается как интерфейс прикладного программирования и действует как стабильный посредник между двумя системами. Подобно тому, как пользовательский интерфейс (UI) соединяет пользователя с системой, API-интерфейсы соединяют одну систему с другой системой или один программный компонент с другим. Большинство API-интерфейсов известны как веб-API, поскольку они связывают веб-страницы с другими приложениями или базами данных.
API-интерфейсы часто визуализируются как официанты в ресторане, где клиент — одна система, а кухня — другая.
API официанта сообщает клиенту, какие услуги доступны, может ретранслировать запросы на кухню и может получить доступ к ограниченной информации, такой как позиция заказа в очереди. Клиенту не нужно знать особенности того, как работает этот ресторан или как обрабатываются их заказы, вместо этого он может просто placeOrderи доверять тому, что API официанта переведет это в соответствии с его внутренней кухонной системой.
Исходя из этого, мы можем видеть, что API-интерфейсы предоставляют уровень абстракции, позволяющий другим системам делать запросы или вызовы API без необходимости доступа к специфике серверной части.
Например, в операционных системах есть API-интерфейсы, которые позволяют разработчикам изменять внешний вид кнопки. Разработчику не нужно знать, какой тип системы использует пользователь, или вручную кодировать поведение, которое делает его кнопкой. Вместо этого они могут просто попросить API отобразить кнопку, и API переведет этот вызов в термины, понятные операционной системе.
Эта абстракция отлично подходит для разработчиков, потому что это означает, что они могут разрабатывать свой продукт для стабильного API, и им не нужно беспокоиться о том, чтобы вручную реализовать эту функцию для каждой системы или их приложение сломается при изменении серверной системы.
Существуют различные типы API-интерфейсов, которые разработчики часто используют, чтобы сделать свои приложения более связанными с внешними технологиями.
Например, Facebook API может позволять пользователям делиться целями из своего фитнес-приложения, или Stripe API может позволять приложению использовать доверенный сторонний сервис транзакций для совершения покупок.
Преимущества API
Абстракция — не единственное преимущество, которое предлагают API. Давайте рассмотрим некоторые из лучших преимуществ, которые вы можете получить от использования
Внешнее использование
Если ваше приложение станет популярным, другие технологии могут запросить API для взаимодействия с вашей системой. В результате вы, по сути, получите бесплатную рекламу, а в конечном итоге и пользователей, потому что она представляет ваш продукт новым группам пользователей.
Например, веб-приложения могут включать кнопку «Купить на Amazon», чтобы клиенты могли легко сделать следующий шаг. Это улучшает качество обслуживания пользователей приложения. В то же время Amazon получает выгоду, потому что открывает пользователям доступ к своему бренду каждый раз, когда они входят в систему, даже если это приложение, отличное от Amazon.
Безопасность
Поскольку API-интерфейсы действуют как буфер между системами, они позволяют вам выбирать, какое поведение вы разрешаете, а какое нет. Вместо того, чтобы использовать все или ничего, пользователи могут сделать более индивидуальный выбор, исходя из своих предпочтений в отношении конфиденциальности.
Например, вы можете использовать интеграцию приложения Twitter API для публикации изображения в социальных сетях, но не хотите, чтобы приложение знало ваше местоположение. С помощью API вы можете использовать одну службу (сообщение), не разрешая автоматически другую (совместное использование местоположения). Поскольку существует определенное количество API-интерфейсов, которые могут получить доступ к мобильному местоположению, ОС легко определить, когда это было предпринято, и запросить одобрение от пользователя. Этот выбор сделает ваших конечных пользователей более комфортными и сделает их работу лучше.
Более быстрое производство
API-интерфейсы облегчают программистам быстрое создание приложений, поскольку они оптимизируют количество устройств, которые им необходимо учитывать, и позволяют им импортировать внешние API-интерфейсы для добавления определенных ключевых функций. Например, вы можете создать приложение, которое позволит пользователям находить события восходящих художников в их районе.
В первую очередь эти разработчики должны быть заинтересованы в том, чтобы система создания событий работала хорошо и пользователи могли легко просматривать результаты. Хотя им по-прежнему нужна карта и система продаж, они могут использовать партнерские API, такие как Google Maps API, для визуализации точной карты и Salesforce eCommerce API для обработки продаж.
Автоматизация
API также невероятно полезны для автоматизации тестирования. Раньше тестировщикам приходилось полагаться на настраиваемые сценарии, внешние веб-службы и прямую интеграцию для удовлетворения своих потребностей в тестировании. Хотя это работает в небольшом масштабе, прямая интеграция делает среду тестирования негибкой при работе с различными инструментами и ограничивается небольшим количеством тестов. Абстракция, предоставляемая API, позволяет тестировщикам создавать общие наборы тестов в файлах XML или JSON и использовать их в любой системе, интегрированной с их API.
Типы API
API-интерфейсы подразделяются на три фактора: кто должен их использовать, какие протоколы они используют и как они интегрируются с другими аспектами системы. Знание этих типов поможет вам использовать API, управлять дизайном API и даже во время текущего управления API. Мы рассмотрим каждый пример API, чтобы понять различия между каждым типом.
Политика выпуска
API-интерфейсы обеспечивают определенный уровень доступа для всех, кто их интегрирует, однако мы не хотим предоставлять потребителям такой же доступ, как корпоративным клиентам или другим внутренним командам. В результате у нас есть политики выпуска, которые определяют, какой доступ API предоставляет системе.
Существует три уровня доступа: частные API, партнерские API и общедоступные API.
- Частные API — это внутренние API, которые используются только внутри компании. Они предлагают высочайший уровень доступа и позволяют тем, кто находится в одной рабочей экосистеме, получать доступ к данным, редактировать функциональные возможности и при желании видеть некоторую сложность серверной части.
Частные API-интерфейсы отлично подходят для крупных компаний-разработчиков программного обеспечения, таких как Microsoft, которые разделены на множество разных команд, поскольку они позволяют всем командам получать доступ к стандартному набору веб-служб.
- Партнерские API предоставляются избранным бизнес-партнерам, чтобы разрешить одобренное использование для доступа к API. Например, eBay может использовать систему партнерского API, чтобы разрешить проверенным поставщикам делать покупки из их списков, но некачественные или небезопасные продавцы не могут.
Это позволяет разработчикам приложений обеспечивать соблюдение стандартов контроля качества и поддерживать репутацию бренда на высоком уровне, разрешая только приложениям высокого стандарта использовать свои API.
- Общедоступные API-интерфейсы, иногда называемые «открытыми API-интерфейсами», доступны для всеобщего использования в формате, аналогичном формату программного обеспечения с открытым исходным кодом. Большинство API-интерфейсов платформы, таких как Microsoft или Apple Cocoa, являются общедоступными, что позволяет разработчикам легко создавать приложения на своих платформах.
Протоколы API
Протоколы — это набор стандартизированных правил, которые определяют, как должны быть созданы API, чтобы упростить реализацию новых API быстро и в согласованном формате.
- REST API означает передачу репрезентативного состояния. Он в основном используется для обмена документами в веб-службах. Приложения REST предназначены для определения приоритетности масштабируемости компонентов и простоты интерфейсов.
Для этого правила REST требуют, чтобы вы использовали только функции CRUD, независимо от сложности команды. Это означает, что REST приложение используют простые методы HTTP, такие как GET, POST, DELETE, и PUT. Хотя может показаться нелогичным пренебрегать частью ваших инструментов, в конечном итоге это заставляет вас описывать сложное поведение в простых, масштабируемых терминах.
- RPC означает удаленный вызов процедур и предназначен для вызовов API к методам сервера, а не для совместного использования документов. Другими словами, REST API сосредоточены на извлечении ресурсов с сервера для выполнения действий на стороне клиента, в то время как RPC фокусируется на отправке запросов действий для выполнения сервером. Это приводит к более последовательному взаимодействию, но не так масштабируемо.
RPC — это более старый стиль протокола, который в значительной степени игнорируется в пользу REST API.
- SOAP — это аббревиатура от Simple Object Access Protocol. Это стандартный протокол связи, который позволяет взаимодействовать между разными операционными системами. В основном он используется для создания, обновления и извлечения данных из общих баз данных.
SOAP предназначен для обеспечения универсальности за счет поддержки всех основных операционных систем и языков программирования веб-сервисов, таких как Python, JavaScript и Java.
Архитектурный стиль API
Архитектура приложения — это правила и принципы проектирования, которые управляют структурой и потоком системы. Протоколы — это один из аспектов архитектуры системы. Если протоколы — это правила для обмена сообщениями API на микроуровне, то архитектуры — это план на макроуровне того, как все сочетается друг с другом.
В области веб-сервисов доминируют два основных типа архитектуры:
- Сервис-ориентированная архитектура (SOA) является более старой из двух архитектур. В отличие от предыдущих монолитных приложений, которые обрабатывали все, приложения SOA передают некоторые функции разным приложениям, которые слабо связаны через шаблон интеграции.
Хотя SOA решила многие проблемы монолитных структур, отсутствие централизованного управления может усложнить работу, если другие связанные приложения будут обновлены.
- Микросервисная архитектура — это итерация SOA. Он поддерживает слабосвязанную структуру, но добавляет общую систему связи, часто через RESTful API. Эта система позволяет отдельным компонентам обмениваться данными быстрее, сокращая преобразование данных между службами. Микросервисные архитектуры почти всегда используются вместе с REST API.
Они набирают популярность, потому что каждый сервис можно повторять и улучшать без риска повлиять на другие сервисы. Каждый из них достаточно изолирован, чтобы его можно было адаптировать, и абстрагирован, чтобы изменения одной службы не нарушали работу других.
Что изучать дальше
API может быть непросто понять новичку, но он быстро станет ценным инструментом для вас как разработчика веб-приложений. По мере того, как вы продолжаете изучать API, следующий шаг — научиться использовать некоторые популярные API, например:
- Stripe API для покупок в приложении
- Auth0 API для аутентификации клиента
- Facebook API для интеграции с Facebook
- Алголия для быстрых результатов поиска
