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

이전 기사에서는 Asp.Net 라우팅 시스템을 분석했습니다. 오늘은 Asp.Net Web API가 WebHost 모드로 배포될 때 Asp.Net Web API의 라우팅 시스템이 어떻게 내부적으로 구현되는지 간략하게 분석하겠습니다. 간단한 예부터 시작해 보겠습니다.

빈 WebApi 프로젝트를 생성하고 전역에 라우팅 정보 등록:

  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이라는 컨트롤러 생성:

  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를 입력합니다. , 결과는 다음과 같습니다.

Asp.Net Web API의 예를 간략하게 살펴보고, 다음 Asp.Net Web API의 라우팅 시스템을 분석하기 시작합니다.

먼저 Asp.Net Web API에서 경로를 등록하는 방법을 다음과 같이 살펴보겠습니다.

이 경로 등록에는 어떤 작업이 숨겨져 있는지 살펴보겠습니다. 프로세스? ? 아래는 소스 코드입니다:

찾아보기 소스코드에서는 HttpRouteCollection 타입의 확장 메소드인 MapHttpRoute를 호출하여 Asp.Net Web API에서의 경로 등록이 실제로 구현되는 것을 볼 수 있다. MapHttpRoute 메소드에서는 생성된 라우팅 객체가 호출되어 저장되는 것을 볼 수 있다. HttpRouteCollection 개체의 메서드를 추가합니다. GlobalConfiguration의 정적 속성은 Configuration을 통해 RouteTable.Routes를 구성 매개 변수로 사용하여 HostedHttpRouteCollection 유형에 의해 생성되고 HostedHttpRouteCollection 유형은 HttpRouteCollection 유형의 하위 클래스이므로 HostedHttpRouteCollection 유형에서 HostedHttpRouteCollection 하위 클래스는 Add 메서드와 CreateRoute를 재정의합니다. 해당 메소드는 아래와 같으므로 실제 생성된 라우팅 객체는 HostedHttpRoute이며, 이 라우팅 객체는 전역 라우팅 테이블에 저장되어 있음을 알 수 있다. 전역 라우팅 테이블은 HostedHttpRoute입니다. 그렇다면 등록된 라우팅 객체를 글로벌 라우팅 테이블에 저장하는 용도는 무엇인가?

위의 소스코드에서 볼 수 있듯이 마지막으로 생성된 라우팅 객체가 HostedHttpRoute 타입이어서 이제 문제가 생겼습니다. , 앞서 등록했습니다. 라우팅할 때 RouteHandler 및 HttpHandler가 라우팅 개체에 추가되지 않습니다. HostedHttpRoute 객체를 생성하는 과정에서 숨겨진 비밀은 무엇입니까? 계속해서 소스 코드를 살펴보겠습니다.

위의 분석을 통해 지금까지 Asp.Net Web API가 WebHost 모드로 호스팅될 때 등록된 라우팅 개체는 전역 라우팅 테이블 RouteTable.Routes에 저장되는 HostedHttpRoute 유형의 인스턴스임을 알 수 있습니다. 요청을 처리하는 데 사용되는 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을 통해 요청을 가로채고 글로벌 라우팅 테이블에서 순차적으로 일치시켜 후속 처리를 위해 요청 Url과 일치하는 RouteData를 얻는다는 것을 알 수 있습니다. . Asp.Net Web API에서는 위에서 전역 라우팅 테이블에 저장된 라우팅 개체가 HostedHttpRoute 유형이라는 것을 알고 있습니다. Asp.Net Web API에서 최종적으로 일치하는 RouteData를 얻는 방법을 계속 분석해 보겠습니다.

UrlRoutingModule에서는 각 라우팅 개체의 GetRouteData 메서드를 순차적으로 호출하여 RouteData를 얻습니다. Asp.Net Web API에서는 라우팅 개체 유형이 HostedHttpRoute이므로 GetRouteData 메서드를 호출하면 어떤 일이 발생하는지 살펴보겠습니다.

보시다시피, HostedHttpRoute에서 RouteData는 OriginalRoute 속성의 GetRouteData 메서드를 통해 가져옵니다. 이전 분석에서 우리는 이 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 라우팅 시스템의 일치 규칙을 통해 경로 일치가 수행되지만 자체 제약 조건 확인 규칙이 구현됩니다.

위 내용은 이 글의 전체 내용입니다. 모든 분들의 학습에 도움이 되기를 바랍니다.

Asp.Net 웹 API 라우팅 시스템---WebHost 배포 방법에 대한 더 많은 기사를 보려면 PHP 중국어 웹사이트를 주목하세요!