웹 라우팅 (Web Routing)

웹 라우팅(Web Routing)은 서버에 들어온 HTTP 요청의 URL 경로를 보고, 프레임워크에 따라서는 HTTP 메서드까지 따져 그 요청을 처리할 코드를 고르는 규칙입니다. 서버 측 웹 애플리케이션에서 요청과 처리 함수를 연결하는 데 쓰입니다. 경로 패턴과 그에 맞는 요청을 처리할 핸들러 함수의 짝을 라우트(route)라고 부릅니다.

요청 경로와 핸들러 함수의 연결

MDN의 클라이언트-서버 개요에 따르면 브라우저의 HTTP 요청에는 대상 자원을 가리키는 URL과 GET, POST 같은 메서드가 들어 있습니다. 웹 서버는 설정의 패턴 매칭 규칙에 따라 동적 요청을 웹 애플리케이션에 넘기고, 웹 애플리케이션은 /best/ 같은 URL에서 요청의 목적을 파악합니다. 같은 문서는 자원별 URL을 특정 핸들러 함수에 연결하는 장치를 서버 측 웹 프레임워크의 중요한 기능으로 꼽습니다. 이렇게 연결해 두면 어떤 기능을 제공하는 URL을 한곳에서 바꿔도 핸들러 함수는 고치지 않아도 됩니다.

Express 라우팅 안내서는 라우팅을 애플리케이션의 엔드포인트(URI)가 클라이언트 요청에 응답하는 방식으로 정의합니다. Express에서는 HTTP 메서드에 대응하는 app 객체의 메서드로 경로와 핸들러 함수를 등록하며, GET 요청은 app.get(), POST 요청은 app.post()가 받습니다. 경로 /users/:userId/books/:bookId로 /users/34/books/8989 요청이 오면 핸들러는 req.params에서 userId 값 "34"와 bookId 값 "8989"를 읽습니다.

Django 5.2 URL 디스패처 문서에 따르면 Django는 URLconf라는 Python 모듈의 urlpatterns에 든 path()와 re_path() 항목을 순서대로 검사하고, 요청 URL과 처음 일치한 패턴에서 멈춥니다. 이어서 일치한 패턴의 뷰(view)를 HttpRequest 객체와 URL에서 잡은 값으로 호출합니다. 패턴 articles/<int:year>/<int:month>/는 /articles/2005/03/ 요청에서 views.month_archive(request, year=2005, month=3)를 호출하며, int 변환기가 지정돼 있어 연도와 월은 정수로 넘어갑니다.

라우트가 비교하는 요청 정보의 범위

Express 라우팅 안내서는 쿼리 문자열이 라우트 경로에 포함되지 않는다고 경고합니다. Django URL 디스패처 문서도 URLconf가 GET·POST 매개변수와 도메인 이름을 빼고 요청 URL을 비교한다고 설명합니다. 이 문서의 예에서는 끝에 ?page=3이 붙은 요청도 같은 myapp/ 경로로 비교됩니다.

HTTP 메서드를 다루는 방식은 두 프레임워크가 다릅니다. Express 안내서는 라우트 경로와 요청 메서드의 조합이 엔드포인트를 정한다고 설명하므로, 같은 / 경로에도 GET과 POST 핸들러를 따로 붙일 수 있습니다. Django 문서에 따르면 URLconf는 요청 메서드를 보지 않아서 같은 URL로 온 POST, GET, HEAD 요청이 모두 같은 함수로 전달됩니다. 그래서 Django에서 메서드별로 다르게 처리하는 일은 뷰 쪽 코드가 맡습니다.

패턴의 순서와 경로의 정확한 모양도 결과를 바꿉니다. Django 문서의 예에서 /articles/2003/ 요청은 articles/<int:year>/ 패턴과도 맞지만, 목록에서 더 앞에 둔 articles/2003/ 패턴에 먼저 일치합니다. 끝 슬래시가 빠진 /articles/2003은 모든 패턴이 슬래시로 끝나므로 어느 패턴과도 맞지 않고, 일치하는 패턴이 없으면 Django는 오류 처리 뷰를 호출합니다. Express에서는 라우트 경로가 요구하지 않는 끝 슬래시가 요청 URL에 붙었을 때 일치로 볼지를 strict routing 설정이 정합니다.

라우트를 나누고 고칠 때의 조건

Express 라우팅 안내서는 express.Router로 만든 라우터 모듈을 app.use('/birds', birds)처럼 경로에 마운트해 /birds와 /birds/about 요청을 처리하는 예를 보여 줍니다. 상위 경로의 매개변수를 하위 라우트에서 읽으려면 express.Router에 mergeParams 옵션을 넘겨야 합니다. Django URL 디스패처 문서의 include()는 그때까지 일치한 URL 부분을 잘라 내고 남은 문자열을 포함된 URLconf로 넘기며, 상위 URLconf에서 잡은 매개변수도 함께 전달합니다.

Django는 URL을 코드에 직접 적는 대신 이름으로 되찾는 역참조(reverse resolution)를 제공합니다. 패턴에 이름을 붙여 두면 템플릿의 url 태그나 Python 코드의 reverse() 함수로 실제 URL을 얻고, 주소를 바꿀 때는 URLconf 항목만 고치면 됩니다. 다만 여러 앱이 같은 URL 이름을 쓰면 reverse()가 찾는 URL은 urlpatterns에서 마지막에 놓인 패턴이 결정합니다. 문서는 앱 이름 접두어나 'admin:index' 같은 URL 네임스페이스로 이런 충돌을 줄이도록 안내합니다.

핸들러를 더하거나 순서를 바꿀 때는 제어 흐름도 함께 봅니다. Express 안내서에 따르면 한 라우트에 둔 여러 콜백 함수는 각자 next()를 호출해야 다음 콜백으로 제어를 넘기고, next('route')를 호출하면 남은 콜백을 건너뛰어 다음에 일치하는 라우트로 이동합니다. 핸들러가 응답을 끝내지 않고 다음 처리로도 넘기지 않으면 요청-응답 주기가 끝나지 않아 클라이언트 요청이 응답을 받지 못한 채 남습니다.