HttpResponseMessage 대신 IHttpActionResult를 사용해야하는 이유는 무엇입니까?

나는 WebApi로 개발하고 있으며 WebApi2로 이동하여 Microsoft가 a IHttpActionResult를 반환하는 데 사용되는 것이 좋습니다 새 인터페이스를 도입 했습니다 HttpResponseMessage. 이 새로운 인터페이스의 장점에 대해 혼란스러워합니다. 주로을 만드는 약간 쉬운 방법을 제공하는 것 같습니다 HttpResponseMessage.

나는 이것이 "추상화를위한 추상"이라고 주장 할 것이다. 뭔가 빠졌습니까? 이 새로운 인터페이스를 사용하면 한 줄의 코드를 저장하는 것 외에도 실제로 얻을 수있는 이점은 무엇입니까?

기존 방식 (WebApi) :

public HttpResponseMessage Delete(int id)
{
    var status = _Repository.DeleteCustomer(id);
    if (status)
    {
        return new HttpResponseMessage(HttpStatusCode.OK);
    }
    else
    {
        throw new HttpResponseException(HttpStatusCode.NotFound);
    }
}

새로운 방법 (WebApi2) :

public IHttpActionResult Delete(int id)
{
    var status = _Repository.DeleteCustomer(id);
    if (status)
    {
        //return new HttpResponseMessage(HttpStatusCode.OK);
        return Ok();
    }
    else
    {
        //throw new HttpResponseException(HttpStatusCode.NotFound);
        return NotFound();
    }
}

IHttpActionResult기존 코드 HttpResponseMessage가 미리 준비된 응답 중 하나에 맞지 않는 코드를 작성하므로 사용하지 않기로 결정할 수 있습니다 . 그러나 의 미리 준비된 답변 HttpResponseMessage을 IHttpActionResult사용하여 적응할 수 있습니다 ResponseMessage. 이것을 알아내는 데 시간이 걸렸습니다. 따라서 반드시 하나를 선택할 필요가 없다는 것을 게시하고 싶었습니다.

public IHttpActionResult SomeAction()
{
   IHttpActionResult response;
   //we want a 303 with the ability to set location
   HttpResponseMessage responseMsg = new HttpResponseMessage(HttpStatusCode.RedirectMethod);
   responseMsg.Headers.Location = new Uri("http://customLocation.blah");
   response = ResponseMessage(responseMsg);
   return response;
}

참고 ResponseMessage기본 클래스의 방법 ApiController컨트롤러가 상속해야한다고.

계속 사용할 수 있습니다 HttpResponseMessage. 그 능력은 사라지지 않을 것입니다. 나는 당신과 같은 방식을 느꼈고 추가 추상화가 필요하지 않다고 팀과 광범위하게 논쟁했습니다. 그것의 존재를 정당화하려고 노력하는 몇 가지 논쟁이 있었지만 그것이 가치가 있다고 나에게 확신시키는 것은 없었습니다.

그건 내가 브래드 윌슨 에서이 샘플을 볼 때까지 입니다. 체인화 할 수있는 방식으로 클래스 를 구성 하면을 생성하기위한 "액션 수준" 응답 파이프 라인 을 만들 수 있습니다 . 커버 아래에서 이것은 구현 방법 이지만 동작 필터를 읽을 수없는 이유 중 하나 인 동작 방법을 읽을 때 그 순서는 명확하지 않습니다.IHttpActionResultHttpResponseMessageActionFiltersActionFilters

그러나 IHttpActionResult액션 메소드에 명시 적으로 연결할 수 있는 것을 작성하면 모든 종류의 다양한 동작을 구성하여 응답을 생성 할 수 있습니다.

다음의 몇 가지 이점이 있습니다 IHttpActionResult이상 HttpResponseMessage에서 언급 한 마이크로 소프트 ASP.Net 문서는 :

• 컨트롤러의 단위 테스트를 간소화합니다.
• HTTP 응답을 작성하기위한 공통 로직을 별도의 클래스로 이동합니다.
• 응답 구성에 대한 하위 레벨 세부 사항을 숨겨 컨트롤러 조치의 의도를보다 명확하게합니다.

그러나 다음은 IHttpActionResult언급 할 가치가있는 다른 장점입니다 .

• 단일 책임 원칙 존중 : 조치 메소드가 HTTP 요청을 처리하는 책임을 갖도록하고 HTTP 응답 메시지 작성에 관여하지 않습니다.
• System.Web.Http.Results에 이미 정의 된 유용한 구현 즉, Ok NotFound Exception Unauthorized BadRequest Conflict Redirect InvalidModelState( 전체 목록으로 연결 )
• 기본적으로 비동기 및 대기 를 사용합니다 .
• ExecuteAsync메소드 를 구현 하여 자신 만의 ActionResult를 쉽게 만들 수 있습니다 .
• HttpResponseMessage를 IHttpActionResult로 변환 하는 ResponseMessageResult ResponseMessage(HttpResponseMessage response)데 사용할 수 있습니다 .

// this will return HttpResponseMessage as IHttpActionResult
return ResponseMessage(httpResponseMessage); 

이것은 내 개인적인 의견이며 웹 API 팀의 사람들은 아마도 더 잘 설명 할 수 있지만 여기에는 2c가 있습니다.

우선, 나는 그것이 서로의 문제가 아니라고 생각합니다. 당신은 모두 당신이 당신의 행동 방식에 수행 할 작업에 만의 진정한 힘을 이해하기 위해 따라 사용할 수 있습니다 IHttpActionResult당신은 아마의 그 편리 헬퍼 메소드 이외의 단계로해야합니다, ApiController등 Ok, NotFound등

기본적으로 클래스 IHttpActionResult는의 팩토리로 구현한다고 생각합니다 HttpResponseMessage. 그런 생각을 가지게되면, 그것은 돌려 주어야하는 물건과 그것을 생산하는 공장이됩니다. 일반적인 프로그래밍 의미에서, 어떤 경우에는 객체를 직접 만들 수 있으며, 어떤 경우에는 그렇게하기 위해 팩토리가 필요합니다. 여기도 마찬가지입니다.

복잡한 로직을 통해 구성해야하는 응답 (예 : 많은 응답 헤더 등)을 반환하려는 경우 모든 로직을 동작 결과 클래스로 추상화 IHttpActionResult하여 여러 동작 메서드에서 사용하여 응답을 반환 할 수 있습니다.

IHttpActionResult반환 형식 으로 사용 하는 또 다른 이점 은 ASP.NET 웹 API 작업 방법을 MVC와 유사하게 만든다는 것입니다. 미디어 포맷터에 걸리지 않고 작업 결과를 반환 할 수 있습니다.

물론 Darrel이 지적했듯이 API 파이프 라인에서 작업 결과를 연결하고 메시지 처리기 자체와 유사한 강력한 마이크로 파이프 라인을 만들 수 있습니다. 이것은 당신의 행동 방법의 복잡성에 따라 필요할 것입니다.

긴 이야기는 짧습니다 . IHttpActionResult대결 이 아닙니다 HttpResponseMessage. 기본적으로 응답을 작성하는 방법입니다. 직접 또는 공장을 통해 수행하십시오.

: 웹 API는 기본적으로 개체의 4 종류 반환 void, HttpResponseMessage, IHttpActionResult, 등의 강력한 유형. 웹 API의 첫 번째 버전은 HttpResponseMessageHTTP 응답 메시지를 매우 간단하게 반환 합니다.

의 IHttpActionResult일종 인 WebAPI 2에 의해 소개되었습니다 HttpResponseMessage. ExecuteAsync()을 만드는 방법 이 포함되어 있습니다 HttpResponseMessage. 컨트롤러의 단위 테스트를 단순화합니다.

다른 반환 유형은 미디어 포맷터를 사용하여 웹 API에 의해 응답 본문에 직렬화 된 강력한 유형의 클래스입니다. 단점은 404와 같은 오류 코드를 직접 반환 할 수 없다는 것입니다 HttpResponseException. 오류를 던지기 만하면 됩니다.

오히려 IHttpActionResult에 대한 TaskExecuteAsync 인터페이스 함수를 구현하고 싶습니다. 다음과 같은 것 :

    public Task<HttpResponseMessage> ExecuteAsync(CancellationToken cancellationToken)
    {
        var response = _request.CreateResponse(HttpStatusCode.InternalServerError, _respContent);

        switch ((Int32)_respContent.Code)
        { 
            case 1:
            case 6:
            case 7:
                response = _request.CreateResponse(HttpStatusCode.InternalServerError, _respContent);
                break;
            case 2:
            case 3:
            case 4:
                response = _request.CreateResponse(HttpStatusCode.BadRequest, _respContent);
                break;
        } 

        return Task.FromResult(response);
    }

여기서 _request는 HttpRequest이고 _respContent는 페이로드입니다.

IHttpActionResultover 를 사용하면 다음과 같은 이점이 있습니다 HttpResponseMessage.

1. 를 사용하여 IHttpActionResult상태 코드가 아닌 전송되는 데이터에만 집중합니다. 따라서 코드가 더 깨끗하고 유지 관리가 쉽습니다.
2. 구현 된 컨트롤러 방법의 단위 테스트가 더 쉬울 것입니다.
3. 용도 async와 await기본적으로.