Comments 12
Вижу, что у вас в качестве ответа возвращается некоторый OperationResult<T>. Почему именно так, а не просто ActionResult/ActionResult<T>/IActionResult ?
Для стандартизации ответов от всех API по всем микросервисам - структура данных представляет собой, по сути, обертку над типизированным объектом данных T и bool флаг успешности выполнения операции
То есть, вы не опираетесь на коды ответов сервера и он всегда, кроме аварий, должен ответить 200 и внутри будет успех и ответ/неудача? Вопрос был скорее в том, почему не опираетесь на коды ответа. В чем предпочтение?
Да, подход избрали в целом такой, чтобы в одном месте иметь всю информацию для принятия решения о результате операции и о самой операции. Коды ответа пришлось бы на уровне работы с HttpClient обрабатывать, и зависимости от успеха/фейла возвращать данные ответа дальше, а тут мы можем вернуть OperationResult сразу и в одном месте его обработать.
Коды ответа пришлось бы на уровне работы с HttpClient обрабатывать
Вам же все равно коды обрабатывать нужно, никто не защитит от 500, 404, ...
Если успех ответа не определяется кодом ответа, то это не REST API.
А это и не совсем REST API, это по сути надстройка над ним, например как JsonRpc. Преимущество такого подхода в том, что разделяется обработка инфраструктурных ошибок и ошибок бизнес-логики, инфраструктурные ошибки обрабатываются по статус кодам, 404, 500 и т. д. эти ошибки как правило стандартные и обработку их можно вынести в middleware, а вот ошибки валидации, ошибки выполнения бизнес операций и т. д. всегда возвращают статус код 200, но при этом имеют свой формат, свой набор статусов, который намного шире http статусов
Используете ли кодогенерацию, на основе разработанных спецификаций? Или пишете вручную?
В чём сакральный смысл оборачивать код в роутах в одинаковые try {} catch { log.Ex(..) } вместо использования middlware?
Формализуем процесс создания нового API в микросервисах на .NET