Логика продолжения такая:
- После ЛР1–ЛР2 у студента есть домен, требования, подсистемы, ERD и монолитная архитектура. Следующий естественный шаг — описать, какие внешние интерфейсы предоставляет монолит, и как их тестируют (Postman как артефакт проверки и коммуникации).
- OpenAPI (Swagger) — формальный стандарт описания HTTP API, который позволяет людям и инструментам понимать API без чтения исходников, генерировать клиентов/серверные каркасы и тесты. Это прямое развитие «документируем архитектуру» из ЛР3, но уже на уровне контрактов API.
- Для архитектуры важно не «просто Swagger», а ограничение доступов, разделение «публичных/продовых/админских» поверхностей API, и требования по безопасности (включая корректные проверки авторизации, что является типовым риском API).
- Codegen из OpenAPI (Swagger Codegen / OpenAPI Generator) используется в индустрии для генерации SDK, server stubs и документации по спецификации. Это позволяет показать студенту цепочку «контракт → реализация», не сваливаясь в «программирование ради программирования».
- После ЛР3–ЛР4 (микросервисы/варианты клиентов) закономерный следующий шаг — нарезка монолита на микросервисы с формализацией контрактов каждого сервиса: входы/выходы, обязательные поля, модели статусов, ответы/ошибки, версии контрактов, обратная совместимость.