Programing

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

lottogame 2020. 3. 13. 08:11
반응형

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가 미리 준비된 응답 중 하나에 맞지 않는 코드를 작성하므로 사용하지 않기로 결정할 수 있습니다 . 그러나 의 미리 준비된 답변 HttpResponseMessageIHttpActionResult사용하여 적응할 수 있습니다 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당신은 아마의 그 편리 헬퍼 메소드 이외의 단계로해야합니다, ApiControllerOk, 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. 용도 asyncawait기본적으로.

참고 URL : https://stackoverflow.com/questions/21758615/why-should-i-use-ihttpactionresult-instead-of-httpresponsemessage

반응형