Показательный пример того, как меняются ожидания пользователей — "пауза миллениала". Это время в начале аудио/видео записи, которое делает пользователь, чтобы увидеть индикацию записи и убедиться, что запись началась. Пользователи 18-25 лет уже "не ждут" этой индикации и говорят сразу, а значит и софт должен это учитывать и дорабатываться под эти ожидания.
Аналогичным образом меняются ожидания и к внутреннему устройству софта — API. Уже принято, что API использует минимальный набор сущностей: DELETE запрос удаляет сущность, а POST создает. Хотя еще 5-7 лет назад абсолютно нормально было все действия выполнять через POST.
Не существует планетарной рассылки, где рассказывают как меняются ожидания. Нужно держать глаза открытыми.
В этом материале я сфокусируюсь на изменениях API:
- Какие задачи приводят к пересмотру API
- Когда можно менять существующую реализацию, а когда делать новую
- Три уровня изменения API
И затрону еще один аспект — стоит ли считать оптимизацию запроса за новую версию API?
Критерии для определения новой версии API
Как это бывает на практике. Есть API endpoint, который позволяет вернуть продукты с сортировкой по имени
GET /api/v1/products?sort=name
Приходит задача из двух пунктов
- "По какому признаку идет сортировка name" (по алфавиту, по длине?)
- Добавить возможность фильтровать по алфавиту (asc, desc)
То есть позволить делать так
GET /api/v2/products?sort=name&order=desc
И возникает вопрос — нужно ли по-новому назвать этот API endpoint?
Новый API можно считать новой версией при изменении следующих аспектов: