Как сделать API удобным для клиентов, особенно мобильных клиентов:)

Вынесенный в название вопрос кажется парадоксальным — ведь обычно API проектируется как контракт между поставщиками и потребителями программных интерфейсов, а контракт обычно должен быть удобным для всех участников. Но на самом деле вопрос не праздный. В этой статье мы попробуем ответить на него:)

И начнем мы с обсуждения того, как API обычно выглядит глазами поставщиков API (рис. 1). Кажется, что все удобно и на своем месте:

  • есть ряд endpoint’ ов
  • есть ряд клиентов, которые обращаются в эти endpoint’ы за данными

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

  • реализация логики объединения данных на стороне клиента приводит к tight coupling между мобильным приложением и API, а с учетом того, что мобильные приложения живут долго, то это связь тянется тоже дооооолго — дальнейшая эволюция мобильных приложений и API затруднена
  • если приложения пишутся нативные, то часто требуется эту логику реализовывать несколько раз — а именно под Android и под iOS
  • реализация сложного объединения данных фактически на фронте — это не профильная задача мобильных разработчиков, т.е. мы не оптимально используем разделение труда
  • при необходимости изменения логики объединения данных нужен релиз мобильного приложения — а это гораздо дольше и заметнее изменения бекенд сервисов

Возникает вопрос, а как же это можно изменить эту ситуацию к лучшему? И к счастью ответ на этот вопрос дан уже до нас:)

Нам просто нужны удобные фасады, которые позволят получать ответы нужные клиенту сразу в агрегированном виде. Среди стандартных вариантов есть 2 особо популярных:

  • использование архитектурного паттерны Backend For Fronted или для краткости BFF
  • предоставление API в виде GraphQL — open-source языка для выборок и манипуляции данными при обращениях через API

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

Давайте сравним эти варианты. Сводные таблички представлены на рисунке 4.

Ну и напоследок можно указать, что оба варианта уже достаточно давно на рынке и признаны и используются в куче компаний, причем иногда они комбинируются между собой. Интересно, что BFF уже настолько общепринятая практика, что про нее не упоминают дополнительно. Подробнее появление подходов и кто их использует можно посмотреть на рисунке 5.

Если бы мне пришлось выбирать как сделать API удобным, то я бы выбрал вариант с BFF, опираясь на свой текущий опыт. Мне кажется, что формат с query language оставляет слишком много свободы клиентской стороне и требует более аккуратного обращения, чтобы не выстрелить себе в ногу.

Источники

  1. Pattern: Backends For Frontends — определение от Сэма Ньюмана
  2. GraphQL — страничка с Wikipedia
  3. Backends For Frontends — в радаре от ThoughtWorks
  4. Pattern: API Gateway / Backends for Frontends — Крис Ричардсон смешивает паттерны BFF и API Gateway
  5. Backends for Frontends pattern — описание паттерна BFF от Microsoft
  6. Create a backend for frontend application architecture — описание от IBM
  7. GraphQL — официальная страничка языка

Director of digital ecosystem development department at Tinkoff. Bachelor at applied math, Master at system analysis, Postgraduate studies at economics.

Director of digital ecosystem development department at Tinkoff. Bachelor at applied math, Master at system analysis, Postgraduate studies at economics.