Лучший API-интерфейс Web API для возврата HttpResponseMessage

У меня есть проект веб-API, и мои методы всегда возвращают HttpResponseMessage.

Итак, если он работает или не работает, я возвращаюсь:

Нет ошибок:

return Request.CreateResponse(HttpStatusCode.OK,"File was processed.");

Любая ошибка или ошибка

return Request.CreateResponse(HttpStatusCode.NoContent, "The file has no content or rows to process.");

Когда я возвращаю объект, я использую:

return Request.CreateResponse(HttpStatusCode.OK, user);

Я хотел бы знать, как я могу вернуться к моему клиенту HTML5 с лучшей инкапсулированной задержкой, поэтому я могу вернуть дополнительную информацию о транзакции и т.д.

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

Кто-нибудь реализовал нечто подобное?

Ответы

Ответ 1

Хотя это прямо не отвечает на вопрос, я хотел бы предоставить некоторую информацию, которую я нашел полезной. http://weblogs.asp.net/dwahlin/archive/2013/11/11/new-features-in-asp-net-web-api-2-part-i.aspx

HttpResponseMessage более или менее заменен на IHttpActionResult. Это намного проще в использовании.

public IHttpActionResult Get()
{
     Object obj = new Object();
     if (obj == null)
         return NotFound();
     return Ok(obj);
 }

Затем вы можете инкапсулировать, чтобы создавать собственные. Как настроить пользовательские заголовки при использовании IHttpActionResult?

Я еще не нашел необходимости в реализации пользовательского результата, но когда я это сделаю, я перейду по этому маршруту.

Скорее всего, это похоже на использование старого.

Дальнейшее расширение и предоставление дополнительной информации. Вы также можете включать сообщения с некоторыми из запросов. Например.

return BadRequest("Custom Message Here");

Вы не можете сделать это со многими другими, но помогаете распространять сообщения, которые хотите отправить назад.

Ответ 2

Вы можете вернуть ответ об ошибке, чтобы предоставить более подробную информацию.

public HttpResponseMessage Get()
{
    HttpError myCustomError = new HttpError("The file has no content or rows to process.") { { "CustomErrorCode", 42 } };
     return Request.CreateErrorResponse(HttpStatusCode.BadRequest, myCustomError);
 }

Вернется:

{ 
  "Message": "The file has no content or rows to process.", 
  "CustomErrorCode": 42 
}

Подробнее здесь: http://blogs.msdn.com/b/youssefm/archive/2012/06/28/error-handling-in-asp-net-webapi.aspx

Я также использую http://en.wikipedia.org/wiki/List_of_HTTP_status_codes, чтобы помочь мне определить, какой код статуса http будет возвращен.

Ответ 3

Одно важное замечание: не помещайте контент в 204 ответа! Это не только противоречит спецификации HTTP, но и .NET может вести себя неожиданными манерами, если вы это сделаете.

Я ошибочно использовал return Request.CreateResponse(HttpStatusCode.NoContent, null);, и это привело к настоящей головной боли; будущие запросы из того же сеанса будут прерываться из-за наличия строкового значения "null", добавленного к ответу. Я полагаю, что .NET не всегда полностью очищает объект ответа от вызовов API от того же сеанса.