Три фишки хорошего API

Фото: pexels

Сегодня программные интерфейсы приложений (API) находятся в самом центре современной архитектуры ПО.

API – это как пользовательские интерфейсы, только пользователями здесь выступают программы.

Признак успешного API – когда получаешь совсем не то, что планировалось, и люди в итоге создают такие вещи, которые вообще не ожидаешь.

На конференции Apidays один из докладчиков дал дельные советы о том, как избежать наиболее распространенных ошибок на этапе проектирования API.

FinBase.com.ua предлагает отдельно рассмотреть каждый из них.

#1: Используйте HTTP POST вместо GET

Вообще использование HTTP POST встречается достаточно редко, поскольку GET – гораздо более популярный метод получения данных, чем POST. Так сложилось исторически. При этом GET обычно приводит к появлению длинных URL, в которых бывает сложно разобраться. Впрочем, такими является большинство запросов, поэтому GET де-факто стал главным методом построения фильтрованных запросов с помощью HTTP. Также стоит заметить, что длинные URL любит Google, так что они хороши для поисковой оптимизации.

Однако приложения для веба, работающие через браузер, используя GET могут столкнуться с проблемой. Из-за того, что некоторые браузеры (а особенно Chrome) хороши в кешировании, если браузер видит постоянно повторяющийся GET – например, нажатие кнопки назад – в итоге у вас могут возникнуть две посадочные страницы для одной формы.

Даже если с браузером все в порядке, на стороне провайдера наверняка есть кеширующий прокси. Например, если пользователь заходит на веб-сайт из отеля, то ему наверняка возвращают кешированные GET независимо от того, хочет ли пользователь этого или нет. В большинстве случаев совершенно непонятно это кешированная выдача или актуальная.

Чтобы решить эту проблему, лучше пользоваться POST, а не GET, поскольку согласно спецификации HTTP метод POST не кешируется.

Если вы все-таки получаете кешированные API-запросы и сложно понять почему, тогда стоит посмотреть на следующие моменты:

  • Добавьте POST там где это возможно (держите в уме тот факт, что смена GET на POST на изменение взаимодействия с API, а это повлияет на внешние приложения).
  • Добавьте ?cache_buster=[random] к любому GET (это один из способов поддержки статуса-кво, если смена GET на POST может сильно отобразиться на других девелоперских проектах).

#2: Используйте сжатие часто используемых API

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

Чтобы идентифицировать проблему, стоит спросить себя:

  • У вас есть большие дата-сеты?
  • Эти запросы вам дорого обходятся?
  • Ваши данные меняются достаточно часто?
  • У вас большое количество клиентов?

Если на все вопросы вы получаете утвердительный ответ, то в качестве быстрого решения можно использовать вебхуки (webhooks), которые по сути являются обратным API. Вместо того, чтобы спрашивать, мы отправляем им POST когда есть что-то новое. И разница в трафике впечатляет, поскольку вебхуки снижают количество запросов.

Вебхук – это уведомление, которое отправляется в сеть автоматически при возникновении определенного события. Уведомления отправляются через HTTP POST, а тело запроса – в формате JSON.

Кроме этого, можно попробовать и другие способы:

  • кеширование (хотя это скользкий момент)
  • копия базы данных (только для чтения)

#3: Формируйте группы запросов

Что делать, если для обновления всей информации в веб-приложении требуется сделать 10-20 отдельных запросов к API? Обычно такая ситуация приводит к эффекту пробки и существенному замедлению работы приложения. В качестве одного из решений может сброс REST по методу GraphQL.

Суть состоит в том, чтобы подумать как клиент собирается слать запросы и как будет использоваться ваш инструментарий. Это что-то типа N+1 запросов, когда вызов идет на главный элемент, который потом сбрасывается на подчиненные ему элементы. Если найти похожие паттерны в запросах ваших пользователей, то можно снизить количество обращений к API c помощью построения специфического слоя (так называемый бэкэнд для фронтэнда).

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