В книге «Микросервисы. От архитектуры до релиза» авторы предлагают рассматривать API как продукт и прикладывать к его разработке Jobs To Be Done.
Из всей книги эта мысль оказалась для меня самой полезной.
JTBD рассматривает продукт через работу, которую пользователь выполняет с его помощью. Если приложить этот взгляд к API, перед проектированием появляются два вопроса:
- Кто будет пользоваться нашим API?
- Какую работу эти люди хотят с его помощью сделать?
Потребители есть и у внутреннего API. Ими могут быть фронтендеры, мобильные разработчики, смежные команды или специалисты по IoT. Все они решают свои задачи с помощью вашего интерфейса.
Поэтому черновик API полезно показать потребителям до реализации. Достаточно ли данных для их задачи? Удобно ли будет пользоваться интерфейсом? Не потеряли ли мы важный сценарий?
Это не означает, что потребители должны сами спроектировать API. Но их обратная связь должна влиять на решение. Иначе одна сторона «всё напроектировала», а другая не может выполнить свою задачу.
Хорошему разработчику полезно немного разбираться в создании продуктов. Начать можно со своего API: сделать его удобным для разработчиков, которым с ним жить.