Asp.Net Web API 라우팅 시스템 분석---WebHost 배포 방식

이전 포스트에서 우리는 Asp.Net 라우팅 시스템을 분석했고, 이번에는 Asp.Net Web API가WebHost 방식으로 배포될 때, Asp.Net Web API의 라우팅 시스템이 어떻게 내부적으로 구현되는지 간단히 분석해 보겠습니다. 여전히 간단한 예제로 시작해 보겠습니다.

创建一个空的WebApi项目，在Global中注册路由信息：

  public class WebApiApplication : System.Web.HttpApplication
  {
    protected void Application_Start()
    {
      //注册路由
      GlobalConfiguration.Configuration.Routes.MapHttpRoute(
        name: "default",
        routeTemplate: "api"/{controller}}}/{id}", 
        defaults: new { id = RouteParameter.Optional });
    }
  }

Home라는 Controller를 생성합니다:

  public class HomeController : ApiController
  {
    // GET: api/Home
    public IEnumerable<string> Get()
    {
      return new string[] { "value1", "value2" };
    }
    // GET: api/Home/5
    public string Get(int id)
    {
      return "value";
    }
  }

서버를 실행하고, 브라우저 주소 표시줄에 http:을 입력하여 실행합니다://localhost:46351/api/home와 http://localhost:46351/api/home/5결과는 다음과 같습니다:

Asp.Net Web API의 예제를 간단히 확인한 후, Asp.Net Web API의 라우팅 시스템을 분석하기 시작합니다.

먼저 Asp.Net Web API에서 라우팅을 등록하는 방법을 확인해 보겠습니다:

이 라우팅 등록 과정에서 숨겨진 작업은 무엇인가요? 아래 소스 코드를 통해 확인해 보겠습니다:

소스 코드를 통해 볼 수 있듯이, Asp.Net Web API에서는 HttpRouteCollection 타입의 확장 메서드 MapHttpRoute를 호출하여 라우팅을 등록합니다. MapHttpRoute 메서드에서는 생성된 라우팅 객체가 HttpRouteCollection 객체의 Add 메서드를 호출하여 저장됩니다. 또한 GlobalConfiguration의 스태틱 속성은 Configuration는 HostedHttpRouteCollection 타입으로 RouteTable.Routes를 생성자 매개변수로 사용하여 생성되며, HostedHttpRouteCollection 타입은 HttpRouteCollection 타입의 서브클래스입니다. HostedHttpRouteCollection 타입에서는 부모 타입의 Add 메서드와 CreateRoute 메서드를 재정의하였습니다. 그림에서 볼 수 있듯이, 실제로 생성된 라우팅 객체의 타입은 HostedHttpRoute입니다. 이 라우팅 객체는 전체 라우팅 테이블에 저장되었습니다. 따라서 전체 라우팅 테이블에 저장된 라우팅 객체의 타입은 HostedHttpRoute입니다. 등록된 라우팅 객체를 전체 라우팅 테이블에 저장하는 것의 의미는 나중에 분석할 것입니다.

위의 소스 코드에서 볼 수 있듯이, 마지막에 생성된 라우팅 객체가 HostedHttpRoute 타입입니다. 그렇다면, 이전에 라우팅을 등록할 때 RouteHandler와 HttpHandler를 지정하지 않았지만, 이들은 어디에서 라우팅 객체에 추가되었는지 궁금합니다. HostedHttpRoute 객체를 생성하는 과정에서 숨겨진 비밀은 무엇인지, 다음은 소스 코드를 계속 확인해 보겠습니다:

위의 분석을 통해 현재까지, Asp.Net Web API가 WebHost 방식으로 호스팅될 때, 등록된 라우팅 객체가 HostedHttpRoute 타입의 인스턴스로 전체 라우팅 테이블 RouteTable.Routes에 저장되었으며, 요청을 처리하는 RouteHandler와 HttpHandler는 HttpControllerRouteHandler 타입의 인스턴스와 HttpControllerHandler 타입의 인스턴스로 각각 저장되었습니다:

　라우팅 정보를 등록한 후, Asp.Net Web API에서는 등록한 라우팅 정보를 어떻게 사용하여 라우팅을 수행하는지 알고 싶습니다. 그것이 Asp.Net과 마찬가지로 HttpModule을 통해 구현되었을까요? 프로그램을 실행하여 Global 클래스의 Modules 속성을 확인해 보겠습니다:

위 스크린 샷에서 명확하게 볼 수 있듯이, Asp.Net Web API가 WebHost 방식으로 서비스를 호스팅할 때도, ASP.Net과 마찬가지로 UrlRoutingModule을 통해 라우팅을 실현합니다. 이전에 Asp.Net 라우팅 시스템을 분석한 글에서 알 수 있듯이, Asp.Net은 UrlRoutingModule을 통해 요청을 차단한 후, 전체 라우팅 테이블에서 차례대로 일치하는 RouteData를 찾아서 후속 처리를 위해 사용합니다. Asp.Net Web API에서는, 전문에서 알 수 있듯이, 전체 라우팅 테이블에 저장된 라우팅 객체는 HostedHttpRoute 타입입니다. 이제 Asp.Net Web API에서 어떻게 일치하는 RouteData를 얻는지 더 깊이 분석해 보겠습니다:

UrlRoutingModule에서는, 각 라우팅 객체의 GetRouteData 메서드를 차례대로 호출하여 RouteData를 얻습니다. Asp.Net Web API에서는, 라우팅 객체의 타입이 HostedHttpRoute이기 때문에, GetRouteData 메서드를 호출할 때 어떤 일이 일어나는지 보겠습니다:

HostedHttpRoute에서는 OriginalRoute의 GetRouteData 메서드를 통해 RouteData를 얻습니다. 이전의 분석에서 알 수 있듯이, 이 OriginalRoute 속성은 HttpWebRoute 타입입니다:

　위의 분석에서 볼 수 있듯이, Asp.Net Web API가 WebHost 방식으로 배포될 때, 결국은 Asp.Net의 루트 시스템을 통해 매칭 작업이 완료됩니다. 그러나 주의해야 할 점은, HttpWebRoute의 부모 타입의 검증 제약 메서드를 재정의했기 때문에, 제약 검증에 있어서는 Asp.Net Web API가 자신의 방식으로 제약 검증을 수행하는 것입니다:

마지막으로, RouteData 객체와 그 안에 포함된 RouteHandler, HttpHandler를 통해 여러 작업을 수행한 후, Asp.Net Web API는 이를 통해 요청 처리와 응답을 할 수 있습니다.

　결론:

위의 분석을 통해, Asp.Net Web API가 WebHost 방식으로 배포될 때, 등록된 루트는 전체 루트 테이블에 저장되며, RouteData를 얻을 때는 Asp.Net 루트 시스템의 매칭 규칙을 통해 루트 매칭이 이루어지지만, 자신의 제약 검증 규칙을 구현했습니다.

이것이 이 글의 전체 내용입니다. 많은 도움이 되길 바라며, 많은 지원을 해 주시기를 바랍니다.

언급: 이 글의 내용은 인터넷에서 가져왔으며, 원작자의 소유물입니다. 인터넷 사용자가 자발적으로 기여하고 자체적으로 업로드한 내용으로, 이 사이트는 소유권을 가지지 않으며, 인공적인 편집 처리를 하지 않았으며, 관련 법적 책임도 부담하지 않습니다. 저작권 위반이 의심되는 내용이 있으면, notice#w로 이메일을 보내 주세요.3codebox.com에 신고를 하실 때, #을 @으로 변경해 주시고, 관련 증거를 제공해 주세요. 일단 확인되면, 이 사이트는 즉시 위반된 내용을 삭제할 것입니다.

기본 가이드