Виды api по способу реализации

Выбор Request-Response парадигмы API: REST, RPC или GraphQL?

Авторизуйтесь

Выбор Request-Response парадигмы API: REST, RPC или GraphQL?

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

Чтобы сэкономить время, силы, а самое главное деньги, стоит посмотреть на best practices, которые применяются на текущий момент. Это поможет разработать API, который позволит вносить необходимые изменения в будущем. За прошедшие годы появилось несколько форматов API, рассмотрим самые популярные из них.

Request-Response APIs

Первую группу API, которую мы рассмотрим, можно выделить как Request-Response API. Основные отличия данной группы:

• Интерфейс предоставляется через веб-сервер на основе HTTP протокола.
• API определяет набор эндпоинтов.
• Клиенты отправляют запросы для работы с данными(получить/удалить/изменить) на данные эндпоинты.
• Ответ в формате JSON или XML.

Самые популярные request-response API: REST, RPC и GraphQL.

Самый популярный подход на данный момент. Используется такими поставщиками API, как, например, Google, Twitter и GitHub.

Когда мы говорим про REST, мы говорим про ресурсы. Ресурс — это объект, который может быть идентифицирован, назван, адресован или обработан в сети. REST представляет данные как ресурсы и использует стандартные HTTP-методы для представления транзакций создания, чтения, обновления и удаления этих ресурсов, то есть стандартные CRUD операции. По сути, все бизнес-сущности, которыми оперирует сервис, могут быть определены как ресурсы.

Общие правила, которым следует RESTful API:

• Ресурс является частью URL.
• Существительные вместо глаголов, вместо /getUserInfo/123 используем /users/123 .
• Для каждого ресурса создается два URL, один для коллекции, один для экземпляра коллекции, /users и users/123 .
• HTTP-методы GET, POST, UPDATE и DELETE информируют сервер о том, какое действие нужно совершить над данным ресурсом. Различные методы, примененные к одному и тому же ресурсу, выполняют различную функциональность.
• Стандартные коды состояния ответа HTTP возвращаются сервером, указывая на успех или неудачу. Как правило, коды в диапазоне 2XX указывают на успех, коды 3XX указывают на перемещение ресурса, а коды в диапазоне 4XX указывают на ошибку на стороне клиента (например, отсутствие обязательного параметра или слишком много запросов). Коды в диапазоне 5XX указывают на ошибки на стороне сервера.
• Ресурс, который существует только в другом ресурсе, должен быть представлен как подресурс, а не как ресурс верхнего уровня в URL-адресе. Например issues не могут существовать отдельно от репозитория, поэтому URL создания нового issue в GitHub API выглядит таким образом — /repos/:owner/:repo/issues

Помимо типичных операций CRUD, API-интерфейсы REST могут иногда нуждаться в представлении операций, не относящихся к CRUD. В этом случае обычно используются следующие подходы:

1. Передавать действие в теле метода. Например, GitHub использует данный подход для архивации репозитория (прим. PATCH /repos/:owner/:repo).
2. Трактовать действие как подресурс. API GitHub использует этот шаблон для блокировки и разблокировки issue (прим. PUT /repos/:owner/:repo/issues/:number/lock).
3. Использовать отдельный ресурс. Некоторые операции, такие как поиск, ещё сложнее вписать в парадигму REST. Типичная практика в этом случае — использовать только команду действия в URL-адресе API (прим. GET /search/code?q=:query).

• Стандартное имя метода, формат аргументов и коды состояния.
• Использует функционал HTTP.
• Легко поддерживать.

• Большой payload.
• Множественные HTTP-запросы.

Для API, предоставляющего CRUD-операции.

Remote Procedure Call (RPC)

Удаленный вызов процедур (RPC) — это одна из простейших парадигм API, в которой клиент вызывает исполнение блока кода на сервере. В то время как REST рассматривает всё как ресурсы, RPC рассматривает действия. Клиенты обычно передают имя метода и аргументы серверу и получают обратно JSON или XML.

• Эндпоинты содержат имя выполняемой операции.
• Вызовы API выполняются с помощью наиболее подходящего HTTP-глагола: GET для запросов только для чтения и POST для других.

• Очень прост.
• Легковесный payload.
• Высокая производительность.

• Труден в обнаружении.
• Практически нет стандартизации.
• Может быть создано слишком много эндпоинтов.

Для API, предоставляющего действия, которые сложно инкапсулировать в CRUD операциях.

GraphQL

GraphQL — это язык запросов для API, который в последнее время приобрел значительную популярность. Он был разработан внутри Facebook в 2012 году до публичного выпуска в 2015 году. GraphQL позволяет клиентам определять структуру требуемых данных. Сервер возвращает именно эту структуру

Sportmaster Lab , Санкт-Петербург, Москва, Краснодар, можно удалённо , От 100 000 до 350 000 ₽

В отличие от REST и RPC API, GraphQL требует только один эндпоинт URL. Также вам не нужны разные HTTP-методы для описания операции. Вместо этого вы указываете в теле JSON выполняете ли вы запрос или мутацию. GraphQL поддерживает методы GET и POST.

Плюсы:

• Один запрос.
• Возможность добавлять новые поля и типы в GraphQL API, не затрагивая существующие запросы.
• Проще отказаться от использования существующих полей.
• Выполняя анализ логов, поставщик API может выяснить, какие клиенты используют определённое поле. Вы можете скрыть устаревшие поля и удалить их, когда их не используют клиенты. С REST и RPC API сложнее определить, какие клиенты используют устаревшее поле, что затрудняет удаление.
• Small payload.
• GraphQL строго типизирован. Во время разработки проверка типов GraphQL помогает гарантировать, что запрос синтаксически верен и действителен.
• GraphiQL — встроенная в браузер IDE для изучения GraphQL. Данный инструмент позволяет пользователям писать, проверять и тестировать запросы GraphQL в браузере.

Минусы:

• Серверу требуется дополнительная обработка для анализа сложных запросов и проверки параметров.
• Оптимизация производительности запросов GraphQL тоже может быть сложной задачей.
• Внутри компании легко предсказать варианты использования и отладить узкие места в производительности, но при работе с внешними разработчиками эти варианты использования становятся трудными для понимания и оптимизации.

Источник

API в современных приложениях

API или Application Programming Interface можно встретить в большинстве современных приложений и вебсайтов. Уже из названия понятно, что это интерфейс, предлагающий разработчикам готовые блоки для создания приложений. Когда ты пишешь приложение, ты обращаешься к такой «библиотеке» и берешь оттуда необходимые данные.

Пока что все выглядит просто и понятно. Надеемся, что так будет и в дальнейшем и ты быстро разберешься в теме и научиться применять API в своих приложениях. А если нет, то мы постараемся помочь тебе в понимании того, что такое Application Programming Interface и где он применяется.

Что же такое Интернет? Это огромная сеть серверов, связанных между собой. На них и хранятся все сайты, которые ты можешь видеть, когда вводишь определенный УРЛ в строку браузера. В принципе, сервером может стать и твой рабочий ноутбук. Он будет обслуживать твой сайт в сети, например. Кстати, разработчики, работающие над сайтами, создают их на локальных серверах и только после отладки запускают во всемирную паутину для публичного доступа.

Например, если ты введешь в строку браузера twitter.com, то на удаленный сервер популярной соцсети будет отправлен запрос. После получения ответа, браузер отображает страницу. Всякий раз, когда ты заходишь на ту или иную страницу, ты уже взаимодействует с API.

В некоторых компаниях API идет как готовый продукт. Например, если это метеорологический сервис, покупая доступ к Application Programming interface, ты получаешь метеорологические данные.

А теперь посмотрим на то, как можно использовать API в своих собственных приложениях. Один из самых простых примеров – написание приложения, в котором пользователь сможет получать данные по погоде в своем городе. Для этого нам необходимо подготовить HTML макет и подключить соответствующий API, а затем, с помощью нескольких функций заставить это приложение работать.

Как пишется HTML код под приложение, мы здесь разбирать не будем, в этом нет смысла. Приложение писалось в библиотеке React, поэтому тем, кто с ней еще не знаком, некоторые моменты могут быть не совсем понятны, но мы поясним по ходу разъяснения.

Итак, для получения доступа к серверу, мы сделаем функцию, в которой будет запрос к серверу с метеорологическими данными. Это нужно для того, чтобы в последующем, пользователь нашего приложения мог получать данные о погоде в любой момент.

Как это происходит? Пользователь твоего приложения хочет узнать, например, погоду в Москве. Для этого, он вбивает название города в поиск, который ты уже внедрил в приложение и получает результат.

В программе же этот результат достигается следующим образом. Функция getWeather отправляет запрос на сервер и получает ответ.

Дальше, в этой же функции мы спрашиваем, отвечает ли нам сервер. Если статус 404, значит мы не записываем никакие данные. А пользователь увидит undefined, ну или что-то другое, по твоему усмотрению. Если же сервер отвечает, мы записываем ответы в state и, когда пользователь будет вводить, например, «Москва» в поиске приложения, у него отобразятся данные именно по Москве (в нашем случае это температура, название города, страны, погодные условия)

Это пример на React, но ты можешь сделать все это на чистом JS без проблем. Самое главное – понять, как все это работает. Как ты мог убедиться, принцип здесь тоже очень простой – отправка запроса на сервер, получение статуса сервера. Если он недоступен, ты в приложении сообщаешь об этом пользователю, например, в графе «Температура» будет написано «Неизвестно» или любой другой вариант.

Если же сервер доступен, пользователь увидит температуру в своем городе, название города, страну и погодные условия.

А вот как выглядит API Европейского центрального банка. Его можно использовать, например, при создании простейшего конвертера валют. Как видишь, здесь просто объект, в котором есть стандартный набор ключ:значение. Получая доступ к этому серверу, ты можешь сделать конвертер, который поможет твоим пользователям рассчитать курс интересующих их валют.

И это далеко не все. Сегодня очень многие приложения и вебсайты предлагают свои API разработчикам. Например, такой интерфейс есть на сайте GitHub, где в базе можно получить информацию по всем пользователям и определенным критериям. API есть на криптовалютных биржах и с их помощью ты можешь создать свое приложение, которое будет «подтягивать» самые последние и актуальные котировки. Тот же CoinmarketCap работает по этому же принципу. Через Application Programming Interface они получают данные с большинства крупных и не только бирж о токенах.

Предположим, ты хочешь сделать свое приложение и тебе требуется API интерфейс для его реализации. Например, это будет тот же метеорологический софт. Один из способов – воспользоваться гуглом. Но есть один интересный сайт, где предложено множество API — https://rapidapi.com/. Здесь доступна обширная библиотека, которая постоянно пополняется.

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

После этого откроется страница, на которой будут представлены все API нужной категории.

Выбрав подходящий интерфейс, можно переходить к его описанию и документации. Она представлена следующим образом

Как видишь, все очень подробно. Очень многие API в свободном доступе, поэтому если ты сейчас изучаешь, например, JS или библиотеку типа React, ты можешь тренироваться с такими API в написании своих приложений для портфолио. Сервис требует регистрацию, пройти которую можно в том числе с помощью социальных сетей.

Существует два основных типа API – публичные и приватные. Первые встречаются в таких приложениях, как Slack или Shopify. Здесь разработчики делают упор на то, что интерфейсы могут использоваться на сторонних платформах. Подключение к такому API совершенно бесплатно, как и его использование.

Есть также приватные API. Они используются, в основном, внутри компаний. Если у фирмы множество внутренних продуктов, для взаимодействия между ними задействуется такой приватный интерфейс.

Самыми часто используемыми интерфейсами этого типа являются:

• API для работы с документами, загружаемыми в браузер. Например, это относиться к Document Object Model. Этот API позволяет работать с HTML разметкой и стилями CSS. То есть разработчик может менять вид страницы. Все, что появляется на странице достигается как раз благодаря DOM.
• API, которые принимают данные с сервера. Ты уже немного знаком с этой технологией, так как мы ее показали примером выше. Когда мы создавали приложение для отображения погоды или конвертер валют, мы делали это именно с помощью данного типа API. Такой подход позволяет «оживить» вебсайт. Работать с серверами таким образом можно через Fetch API или XMLHttpRequest. Также есть термин AJAX, который описывает всю эту технологию.
• API для работы с графикой. Они широко поддерживаются браузерами. Наиболее известными являются Canvas и WebGL. С помощью таких API ты сможешь программным путем менять данных о пикселях, которые содержатся в элементе html . То есть у тебя появляется возможность создания как двухмерных, так и трехмерных изображений с помощью такой технологии. Простой пример – создание какой-нибудь геометрической фигуры, например, треугольника с последующим импортом в canvas и применения различных фильтров. Конечно, эта технология позволяет создавать и более сложные элементы, в том числе трехмерные объекты. Эти API можно применять вместе с другими, например, с интерфейсами создания анимационных циклов. А здесь у тебя уже появляется возможность менять изображение на экране как играх или мультфильмах.
• Аудио и видео API. Такие интерфейсы специально разработаны для того, чтобы у тебя была возможность поработать с мультимедиа в своем приложении или на сайте. К примеру, ты сможешь разработать свой пользовательский интерфейс для проигрывания аудио или видео записей. Ты сможешь добавлять на экран субтитры, записывать видео или аудио с камеры, а также применять различные видео и звуковые эффекты.
• API различных устройств. В основном, это относится к считыванию данных с разных устройств для удобства работы с приложением. Например, есть специальное API, которое позволяет уточнить местоположения устройства. С его помощью ты сможешь написать свое приложение типа навигатора. Также есть API, которые позволяют уведомлять пользователя о появившихся обновлениях или API для включения вибрации смартфона.
• API для хранения информации на стороне пользователя. Эти интерфейсы пользуются все большей популярностью, так как позволяют хранить данные на стороне клиента, даже если страница перезагружена. При этом, приложение может работать и тогда, когда нет подключения к сети Интернет. К таким интерфейсам можно отнести Web Storage API или IndexedDB API.

Наверное, ты уже понял, хотя бы отчасти, зачем приложению нужен API. Приведем наиболее частые ситуации, когда в твоих приложениях ты будешь использовать такой интерфейс:

• Мобильные приложения. Если ты заглянешь AppStore или Google Play Market, ты найдешь там множество софта, в котором используются API. То есть ты создал какую-то программу, сделал простой API и пользователи приложения будут получать информацию именно через этот интерфейс. Согласись, очень удобно и практично.
• Open Source. Почему бы не использовать нужды твоей аудитории тебе же на благо? Сделал приложение? Создай к нему API, с помощью которого пользователи смогут создавать новые клиенты и сервисы.
• Распределение фронтенд и бэкенд. Здесь речь идет о том, что сделать такое распределение можно, например, с помощью использования различных фреймворков для фронтенда.

В принципе. На этом можно было бы и закончить, ведь ты уже создал интерфейс, пусть, как говорится пользуются (платно или бесплатно, определять тебе). Но на самом деле, это недостаточно. Каким образом пользователи будут обращаться к интерфейсу?

Конечно, это может быть стандартный набор HTTP запросов для получения искомой информации. Но это неправильный подход. Наиболее подходящий вариант – создание собственной библиотеки, которая и будет работать с API и где ты опишешь все самые необходимые способы получения и отправки данных.

Первое, что сразу же приходит на ум –Octokit от GitHub. Это яркий пример таких библиотек. Что касается документации, в ней содержится вся необходимая информация для того, чтобы пользователь библиотеки знал, как отыскать требуемую информацию.

Итак, если ты планируешь создание своего собственного API, возможно, тебе стоит позаботиться и о том, чтобы создать к нему библиотеки. Кстати, если твое приложение будет пользоваться большой популярностью, возможно, кто-то другой создаст библиотеку для работы с API твоего софта.

Наверняка ты видел на страницах с приложениями заветное слово API. Это значит, что ты можешь создать свое собственное приложение и использовать готовый API на определенных условиях (бесплатно, платно, за регистрацию и так далее).

В качестве примера, можно привести API Github. Здесь ты получишь всю информацию о пользователе, его аватарке, подписчиках, репозиториях и иные интересные данные. А если взять API Twitter, здесь можно получить информацию о пользователях, твитах, подписчиках и так далее. Такая информация может быть действительно крайне полезной при разработке сторонних приложений.

Теперь ты знаешь, что такое Application Programming Interface. Ты можешь применять его в своих приложениях или создать приложение и разработать свой API для него, чтобы другие пользовались им.

Источник