Заключая контракт: как осуществить хороший API для (микро)сервиса Архитектуры, масштабируемость
Архитектор ПО, тимлид, системщик. 10+ лет провела в ядре виртуальной машины, потом 5 лет занималась архитектурой в распределенных сервисах (не особенно микро). Последние два года вернулась к системному программированию в Kaspersky OS и погрузилась в дивный мир безопасного программирования.
Закончил кафедру прикладной математики и информатики в МГТУ им. Баумана, подающий надежды junior компании Acronis.
Процесс построения API никогда не проходит без споров. Процесс вывода API в public - это настоящий coming out, которому предшествуют масштабные переделки и даже изменения процессов компании.
В этом докладе мы поговорим про дизайн REST API для сервисов и предложим практический checklist для оценки зрелости API.
Мы обсудим следующее:
- Контрактные выборы и их значимость: RAML vs swagger, API first vs code first. Как сделать выбор и как обеспечить его поддержку на всех уровнях компании?
- Разработка API Guideline. Как сформировать этот свод правил и можно ли форсировать его применение?
- Toolchain. Что можно и что нужно автоматизировать, можно ли проверять безопасность на уровне RAML?
- Внедрение практик на все команды. Как помочь программистам добиться совершенного API и не помешать project-manager'ам выпустить продукт в срок.