Chapter7. 라우팅

라우팅은 요청 URL에 따라 응답 처리 대상(액션)을 결정하는 것 또는 그 구조 자체를 말한다.

7.1 RESTful 인터페이스

RESTful 인터페이스를 잘 사용하면 통일감 있고 의미가 명확한 URL 설계가 가능하다.

  • RESTful 인터페이스는 REST의 측징을 가진 라우트를 말한다.

  • REST는 네트워크의 모든 컨텐츠(리소스)를 URL로 표현한다. 그리고 이러한 URL(리소스)에 HTTP 메서드 (GET-추출, POST-생성, PATCH-변경, DELETE-제거) 등의 방법으로 접근한다.

  • 즉, REST란 무엇(리소스)을 어떻게(HTTP 메서드)할지 표현하는 것이다.

  • Rails 는 원칙적으로 RESTful 인터페이스를 기반으로 라우트를 설계한다.

    • 따라서 Rails에서 제공하는 fomr_with, link_to 등의 뷰 헤퍼는 RESTful 인터페이스를 전제로 설계 되었다.

7.1.1 RESTful 인터페이스의 정의

  • RESTful 인터페이스를 정의할 때는 routes.rb 에서 resources 메서드를 호출한다.

  • 리소스는 CRUD 할 수 있는 정보라고 생각하면 좋다. 아래처럼 routes.rb 파일에 resources :name 형식으로 입력하면 URL 로 액션이 매핑된다.

    • 즉, resources 메서드 한방으로 RESTful 인터페이스가 정의 된다는 것이다.

    Railbook::Application.routes.draw do
  resources :users
  ...
  end

  • HTTP Verb

    Path

    Controller#Action

    Used for

    GET

    /users

    users#index

    display a list of all users

    GET

    /users/new

    users#new

    return an HTML form for creating a new user

    POST

    /users

    users#create

    create a new user

    GET

    /users/:id

    users#show

    display a specific user

    GET

    /users/:id/edit

    users#edit

    return an HTML form for editing a user

    PATCH/PUT

    /users/:id

    users#update

    update a specific user

    DELETE

    /users/:id

    users#destroy

    delete a specific user

    resources 메서드는 뷰 헬퍼(link_to)등 에서 사용할 수 있는 URL 헬퍼 도 자동으로 생성한다. 이러한 헬퍼를 사용함으로써 링크를 보다 직관적으로 사용할 수 있는 것은 물론 라우트 정의에 의존하지 않을 수도 있다.

    헬퍼 이름(_path)

    헬퍼 이름(_URL)

    리턴 값(경로))

    users_path

    users_url

    /users

    user_path(id)

    user_url(id)

    /users/:id

    new_user_path

    new_user_url

    /users/new

    edit_user_path(id)

    edit_user_url(id)

    /users/:id/edit

  • xxx_path 와 xxx_url 의 차이는

    • xxx_path 는 상대경로

    • xxx_url 는 절대 경로

    • xxx_url 는 format 을 인자로 받을 수 있다. 따라서 respond_to 처럼 format 에 따라 각기 다른 응답을 해야할 때에는 xxx_url 을 사용한다.

7.1.2 하나의 리소스 정의

resource 메서

  • resources 는 복수형이다. 즉 여러 개의 리소스를 관리하는 RESTful 인터페이스를 생성한다.

  • 반면 resource는 하나의 리소스를 관리하는 RESTful 인터페이스를 생성한다.

  • 예를 들어 하나의 리소스는 애플리케이션의 설정 정보 등의 리소스를 말한다. 즉 애플리케이션 설정은 당연히 그 애플리케이션에서 유일하므로 /config/15 가 아니라 /config 의 형태로 URL에 접근해야 할 것이다.

  • resource config의 결과는 아래와 같다.

    URL

    액션

    HTTP 메서드

    역할

    /config(:format)

    show

    GET

    설정 정보 화면 표시

    /config/new(:format)

    new

    GET

    신규 설정 등록 화면 표시

    /config(:format)

    create

    POST

    등록 화면에서 입력을 받아 등록 처리

    /config/edit(:format)

    edit

    GET

    기존 설정 수정 화면 표시

    /config(:format)

    update

    PATCH/PUT

    수정 화면에서 입력을 받아 수정 처리

    /config(:format)

    destroy

    DELETE

    지정된 설정 정보를 제거 처리

  • resources 메서드와 거의 비슷하지만 index 액션이 정의 되지 않고, :id를 인자로 받지 않는다.

  • 주의해야할 것은 resource 메서드와 매칭되는 컨트롤러는 반드시 복수형이어야 한다.

    • 즉 config의 컨트롤러 이름은 ConfigsController처럼 복수형이 되어야만 한다.

  • URL 헬퍼도 생성이된다.

    PATH

    URL

    경로

    config_path

    config_url

    /config

    new_config_path

    new_config_path

    /config/new

    edit_config_path

    edit_config_path

    /config/edit

7.1.3 라우트 정의 확인하는 법

  1. 터미널에 rails routes 입력하기

  2. 브라우저에 localhost:3000/rails/info/routes로 접근하기

7.2 RESTful 인퍼테이스의 사용자 정의화

  • Rails에서는 resources와 resource메서드를 사용해 정형적인 라우트를 자동으로 생성할 수 있다. 이러한 간단함이 RESTful 인터페이스의 장점이다.

  • 추가로 옵션을 사용해 더욱 다채롭게 사용할 수 있다.

7.2.1 라우트 매개 변수 제약 조건

constraints 옵션

  • resources 메서드로 자동 생성되는 URL 에는 :id 라는 이름의 라우트 매개 변수가 포함된다.

  • 이 :id 라우트 매개 변수에 제약 조건을 걸 수 있다.

  • 아래와 같은 명령을 입력하면 id의 값은 숫자 1자리 또는 2자리로 제한된다.

resources :books, constraints: { id: /[0-9]{1,2}/}

  • 다만 라우트 매개 변수와 관련된 유효성 검사는 모델에서 하는 것이 기본 이다.

7.2.2 복잡한 제약 조건 설정

제약 클래스를 정의 하자

  • 위와 같이 간단한 제약은 resources의 옵션에서 바로 넣을 수 있지만, 복잡한 제약 조건을 걸기 위해서는 클래스를 만들어야 한다.

  • 순서는 아래와 같다. 아래는 9시부터 18시 까지만 라우팅이 가능한 제약을 만드는 예시.

    1. /models 폴더에 TimConstraint.rb 를 만든다.

    2. 파일이름과 같은 클래스 를 만들고 match? 메서드를 만든다.

    3. class TimeConstraint
  def matches?(request)
    ... 생략
  end
end

    4. routes.rb의 resources 에 제약을 넣으면 된다.

    5. resources :books, constraints: TimeConstraint.new

7.2.3 format 매개 변수 제거

Format 옵션

  • resources 메서드로 RESTful 인터페이스를 만들고, 터미널에 rails routes 를 입력하면 라우팅 정보가 나온다.

  • 이때 경로를 보면 뒤에 (:format) 이 붙어있는게 보인다. 이게 뭐냐면 클라이언트가 html 파일이 아닌 .json 이나 .xml 등과 같은 포맷으로 요청을 날릴 때 이 요청 또한 소화하기 위해 처리해 놓은것이다.

  • 만약 서버가 이런 포맷을 원하지 않는다? 그러면 옵션을 이용해서 없애자.

  • resources :books, format: false

  • 이후 rails routes | grep books 를 입력해서 :format이 사라진걸 확인하자

7.2.4 컨트롤러 클래스와 URL 헬퍼의 이름 수정

controller, as 옵션

  • resources 메서드는 기본적으로 지정된 리소스 이름을 기반으로 대응되는 컨트롤러를 결정하고 URL 헬퍼를 생성한다.

  • 만약 기본으로 지정된 이름이 아닌 다른 이름의 컨트롤러를 매핑하고 싶다면 controller 옵션을 사용하자

    • resources :users, controller

  • URL 헬퍼의 이름만 바꾸고 싶다? 그러면 ad 옵션을 사용하자

    • resources :users as members

    • 기존의 users_path 는 members_path, user_path는 member_path 등으로 변경된다.

7.2.5 모듈 내부의 컨트롤러를 맵핑

namespace, scope 블록

  • 컨트롤러 클래스의 수가 많아지면 모듈을 사용해 컨트롤러를 폴더로 정리해야 한다.

  • 이때는 아래와 같이 컨트롤러 클래스를 생성한다.

    rails generate controller Admin::Books

  • 이렇게 하면 Admin::BooksConttoller가 controllers/admin 폴더에 books_controller.rb 라는 이름으로 생성된다.

  • 이렇게 모듈을 사용한 컨트롤러 클래스에 RESTful 인터페이스를 정의하려면 namespace 블록을 사용한다.

  • namespace :admin do
  resources :books
end

  • 이렇게 하고 rails routes 를 확인해보면 books 앞에 admin이 붙은걸 확인할 수 있음.

    • 즉 너무 길어진다.

  • 만약 길어지는게 싫다면 scope 블록을 사용하면 된다.

  • scope midules: :admin do
  resources :books
end

7.2.6 RESTful 액션 추가

collection과 member 블록

  • resources로 자동 생성되는 라우투는 CRUD에 한정되어 있다.

  • 나만의 라우트를 추가 하고 싶다면 collection 또는 member 블록을 사용하면 된다.

  • collection

    • 이 블록은 이름만 봐도 복수로 표현될 라우트를 추가하는 것.

    • index 와 마찬가지로 :id 라우트 매개 변수가 필요 없다!

  • member

    • 이 블록은 하나의 리소스를 지정해야 한다.

    • 즉 :id 매개변수가 필요하다!

  • resources :reviews do
  collection do
    get :unapproval
  end
  member do
    get :draft
  end
end
---결과---
unapproval_reviews GET /reviews/unapproval(:format)
draft_review            GET /reviews/:id/draft(:format)

7.2.7 RESTful 액션 무효화

only, except 옵션

  • resources :users, except: [ :show, :destroy ]
  • resources :users, only: [ :index, :new, :create, :edit, :update ]

7.2.8 계층 구조를 가진 리소스 표현

resources 메서드 중첩

  • 리소스들이 애플리케이션 내부에서 계층 구조를 갖는 경우가 있다.

  • 예를 들면 book 리소스에는 reviews 리소스가 포함된다.

    • book 은 review를 has_many

    • review는 book에 belongs_to

  • 이러한 모델 관계는 URL 로도 표현해주는 것이 직관적이다. 예를 들면 book_id: 1의 reviews 를 보고 싶을 때는 /books/1/reviews 처럼 해주는게 우리가 생각하는 일반적인 모습과 같을 것이다.

  • 이 때 사용하는게 resources의 중첩 구조다. 사용법과 그로인해 생기는 결과는 아래와 같다.

  • resources :books do
  resources :reviews
end
계층구조에서의 reviews 라우팅 테이블

  • 먼저 xxx_path 의 이름이 기존과 다르게 book_reviews 와 같이 변경됐고, path 에 들어가는 인자도 :id 하나가 아닌 book_id 와 :id 두개가 되었다.

  • 이렇게 만든 상태로 서버에 접근하면 서버 에러가 발생한다. 에러가 발생하는 원인은 간단하다.

    • 먼저 reviews 의 html.erb 파일들에서 사용하고 있던 URL 헬퍼 들이 수정되지 않은 상태다.

      • reviews_path 였다면 book_reviews로 바꿔야 한다.

  • 이런 헬퍼들에 대한 인자가 2개로 바꼈다. 기존에는 review의 :id 하나면 됐지만 이제는 book_id 까지 넣어줘야 한다.

  • 예를 들면 reviews/index.html.erb 파일을 아래처럼 수정해야한다.

    --- 변경 전 ---
<td><%= link_to 'Show', review %></td>
--- 변경 후 ---
<td><%= link_to 'Show', book_review_path(book_id: review.book_id, id: review.id) %></td>

7.2.9 리소스의 얕은 중첩 표현

shallow 표현

  • resources로 중첩표현을 하면 위의 사진처럼 특정 review에 접근하기 위해서는 book 과 관련된 처리까지 해야한다.

  • shallow 옵션을 사용하면 이 번거로움을 해결할 수 있다.

  • resources :books do
  resources :reviews, shallow: true
end
shallow 옵션을 적용했을 때의 reviews 라우팅 테이블

  • :id 매개 변수를 받지 않는 index, new, create 액션은 그대로지만

  • :id 매개 변수를 받는 edit, show, update ... 등은 book_id 가 사라졌음을 확인할 수 있다.

  • shallow를 하드코딩 하는 방법도 있다.

    resources :books do
  resources :reviews, only: [ :index, :new, :create ]
end
resources :reviews, except: [ :index, :new, :create]

7.2.10 라우 정의 재이용

concern 메서드와 concerns 옵션

  • concern 메서드를 사용하면 공통되는 내용을 여러 개의 라우트 정의에 넣을 수 있다.

  • resources :reviews do
  get :unapproval, on: :collection
  get :draft, on: :member
end

resources :users do
  get :unapproval, on: :collection
  get :draft, on: :member
end

  • 위와 같은 라우트 정의는 블록 내부의 내용이 같으므로 concern 메서드로 분리하자.

    concern :additional do
  get :unapproval, on: :collection
  get :draft. on: :member
end

resources :reviews, concern: :additional
resources :users, concerns: :additional

7.3 RESTful 하지 않은 라우트 정의의 기본

  • Rails는 기본적으로 RESTful 인터페이스로 구성된다. 하지만 모든 것을 REST의 사상에 맞춰 만들 수 있는 것은 아니다.

  • 이럴 때는 무리해서 RESTful 인터페이스를 적용하려 들지 말고 간단하게 RESTful 하지 않은 라우트 정의를 사용해도 된다.

    • 무조건 RESTful 인터페이스에 따라 만드는 것이 좋은것은 아니다!

7.3.1 RESTful 하지 않은 라우트 정의의 기본

match 메서드

# match pattern, via: verb [,opts]

match ':controller(/:action(/:id))', via: [ :get, :post, :patch ]

  • 위와 같은 형태로 패턴을 만들면 아래와 같은 패턴이 매치된다.

    • /books

    • /hello/list

    • /blog/details/123

    • blog/details/123.json

  • 괄호로 감싸진 부분은 생략 가능함을 나타낸다.

  • via 옵션은 라우트에 허용할 HTTP 메서드 를 지정한다.

PreviousChapter3. 스캐폴딩NextChapter8. 테스트

Last updated

Was this helpful?