Лучше ли всегда возвращать HttpResponseMessage в Web Api?

Мне это интересно некоторое время, лучше ли всегда возвращать HttpResponseMessage web, используя asp.net mvc web api?

Когда я загружаю проект webapi по умолчанию, я вижу, что он не использует его в контроллере образца

 // GET api/values
        public IEnumerable<string> Get()
        {
            return new string[] { "value1", "value2" };
        }

        // GET api/values/5
        public string Get(int id)
        {
            return "value";
        }

Я думал, что HttpResponseMessage обертывает все вокруг и делает его хорошим Http-запросом. Если это правильно, то в чем преимущество не только его использования?

Ответы

Ответ 1

Я всегда возвращаю HttpResponseMessage. Точка веб-API должна быть способна отображать HTTP-api. Притворяясь, что вы возвращаете объект, а затем полагаетесь на конвейер фреймов для преобразования объекта в HTTPResponseMessage, просто скрывается намерение IMO.

Я уверен, что если вы заплатите дополнительную стоимость за создание самого HttpResponseMessage, вы поймете, как работает веб-API. Вы столкнетесь с меньшими проблемами, потому что у вас больше шансов избежать использования веб-API, что вы не ожидали. Вы, скорее всего, воспользуетесь возможностями HTTP, потому что заголовки находятся там, где вы можете получить доступ.

Ответ 2

Для разделения проблем, почему не имеет уровня обслуживания (сильные типизированные методы в библиотеке классов) и уровня webservice (ASP.NET WEB API).
Уровень сервиса можно легко использовать в Winform, WPF, Console и тестовых проектах без зависимости Http, а также может быть представлен как веб-сервис ASPNET WebAPi, например, для мобильного приложения и/или javascript.
Опасность веб-сервисов заключается в том, чтобы разоблачить сервисный уровень с проблемами http (заголовки, тип контента, http status..), чтобы вы могли вернуть HttpResponseMessage.
Это также делает контроллер очень тонким, и вы можете ввести услугу с помощью DI