Как универсально сформировать Response?

Question

[Oleg Gusev]

Я уже написал достаточно много "тестовых" Web Api для себя, однако, уже давно задаюсь следующим вопросом: "Какой вид response лучше всего отправлять?"

Сейчас как response я отправляю DTO от какого-то класса. Однако, как я понимаю, это не лучший способ.
Мой друг фронтендер говорит, что он работал только с марвел апи и там в качестве ответа приходит массив элементов. Конечно, я могу сделать маппинг полей класса к индексам, но от этого может упасть читаемость кода и тп. С другой стороны, если я отправляю DTO на фронт, то фронтер должен сопоставить свой класс с моим, наверное, это тоже проблематично при большом количестве полей.

Стоит ли вообще приводить response к массиву?

Comments

[Andrei SunnyPh]

Можете попробовать самостоятельно создать стандартный ответ из API.
Например:

public class APIResponse
    {
        public APIResponse()
        {
            ErrorMessages = new List<string>();
        }
        public HttpStatusCode StatusCode { get; set; }
        public bool IsSuccess { get; set; } = true;
        public List<string> ErrorMessages { get; set; }
        public object Result { get; set; }
    }

И такой класс с универсальным ответом из API, будет содержать статус код, признак того обработан ли успешно запрос,
список строк с ошибками и собственно сам результат ответа, как тип Object, где может быть любой тип C#, в том числе массив. Но как по мне это должен быть в любом случае DTO, один или множество, все зависит от запроса.

Далее, как пример, запрос HttpGet, для получения данных, о конкретном экземпляре , мог бы выглядеть примерно так, с использованием стандартного ответа:

public async Task<ActionResult<APIResponse>> GetProductById(int id)
        {
            try
            {
                if (id == 0)
                {
                    _response.StatusCode = HttpStatusCode.BadRequest;    
                    return BadRequest(_response);
                }
               var product = await _productRepository.GetById(id);
                if (product == null)
                {
                    _response.StatusCode = HttpStatusCode.NotFound;
                    return NotFound(_response);
                }
                _response.Result = product;
                _response.StatusCode = HttpStatusCode.OK;
                return Ok(_response);
            }
            catch (Exception ex)
            {
                _response.IsSuccess = false;
                _response.ErrorMessages
                     = new List<string>() { ex.ToString() };
            }
            return _response;
        }

Где _response в данном контексте, это APIResponse.

Пример реализации такого подхода для WEB API в репозитории.

[Петр]

Andrei SunnyPh, А смысл в такой избаточности?
Статус код приходит в http протоколе и вам все равно придется его обрабатывать, так как если придет ошибка сетевого уровня (для примера 503), то без этого никак.
IsSuccess - определяется из статус кода.
List ErrorMessages - ошибка всегда одна, но может содержать уточняющие данные. Лучше string "Error" и list ErrorDetails
При этом Result упакован в обьект. Это почти тоже самое, что изначально спрашивали, паковать ли в массив.

А вот из полезного в случае ошибки у вас нет "Времени запроса", Url самого запроса.

Answer 1

[Сергей Соловьев]

"Какой вид response лучше всего отправлять?"

Какой удобнее. Перед тем как код писать надо хотя бы подумать, в каком виде ответ ожидается/легче использовать.
OpenAPI для согласования API тебе в помощь

С другой стороны, если я отправляю DTO на фронт, то фронтер должен сопоставить свой класс с моим, наверное, это тоже проблематично при большом количестве полей

Есть готовые фреймворки для такого. Например, GraphQL - можно указать что конкретно тебе нужно.
Есть и другие, как OData. Либо можешь свой написать, чтобы клиент сам указывал поля, какие нужны.

Стоит ли вообще приводить response к массиву?

Нигде не видел подобного поведения. Если бы был пример ответа в таком формате, то мог бы сказать.
Если имеется ввиду вместо объекта - массив значений его полей, то это плохая затея.