У меня есть веб-API, который представляет собой действительно тонкую часть инфраструктуры, которая содержит не более двух реализаций DelegatingHandler
, которые отправляют входящие сообщения в реализации обработчика сообщений, которые определены в бизнес-уровне. Это означает, что нет контроллеров и никаких действий контроллера; API определяется только на основе сообщений. Это означает, что никакие изменения кода в этом уровне инфраструктуры не требуются при реализации новых функций.
Например, у нас есть такие сообщения, как:
- CreateOrderCommand
- ShipOrderCommand
- GetOrderByIdQuery
- GetUnshippedOrdersForCurrentCustomerQuery
Обработчики делегирования определяют точное сообщение на основе URL-адреса, а содержимое запроса десериализуется в экземпляр этого типа сообщения, после чего это сообщение пересылается соответствующему обработчику сообщений. Например, эти сообщения (в настоящее время) отображаются на следующие URL:
- API/команды/CreateOrder
- API/команды/ShipOrder
- API/запросы/GetOrderById
- API/запросы/GetUnshippedOrdersForCurrentCustomer
Как вы можете себе представить, этот способ работы с Web API упрощает разработку и повышает производительность разработки; там меньше кода для написания и меньше кода для тестирования.
Но поскольку контроллеров нет, у меня возникают проблемы с загрузкой в Swashbuckle; после прочтения документации я не нашел способ зарегистрировать эти типы URL в Swashbuckle. Есть ли способ настроить Swashbuckle таким образом, чтобы он все еще мог выводить документацию API?
Для полноты приложения эталонной архитектуры, которое демонстрирует это, можно найти здесь.