# 20201229(화)

## 2020-12-29

### 1. 학습 날짜

* 2020-12-29

### 2. 학습 시간

* 10:30 \~ 22:30

### 3. 학습 범위 및 주제

* 루비온레일즈 컨트롤러, 라우팅

### 4. 학습 목표

* 페펙트 루비 온 레일즈 6, 7장

### 5. 과제 제출

* x

### 6. 상세 학습 내용

* 상태관리란 여러 개의 페이지 사이에서 정보를 유지하기 위한 구조다. 쉽게 말하면 로그인의 유무에 따라 클라이언트 페이지에서 동작이 다르게 되야한다는 것이다. 로그인하지 않았을 때는 오른쪽 위에 `로그인` 이라는 버튼이 나오고, 로그인했을 때는 `로그아웃`이 나오게 하는 것도 상태관리의 일종이다. 웹서버는 이런 상태를 유지하기 위해 몇가지 기법을 쓰는데, 그 중 가장 간단한 건 쿠키를 이용하는 것이다. 원칙적으로 서버는 클라이언트의 쿠키를 소유하면 안된다. 하지만 특정한 경우, 상태관리를 할 때는 임시적으로나마 쿠키를 서버에서 갖는게 허용이 된다. 서버는 클라이언트의 쿠키를 확인하고 클라이언트의 상태를 확인한다. 그리고 그에 맞는 응답을 준다. 쿠키 보다 더 좋은 방법은 세션을 사용하는 것이다. 세션도 기본적으로 쿠키를 이용한다. 하지만 세션은 그 쿠키를 저장하는 곳을 정할 수 있다.
  * 그렇다면 왜 상태관리를 이렇게 쿠키 또는 세션을 이용해서 해야하는가? 이유는 간단하다. http 프로토콜의 `무상태 프로토콜` 원칙 때문이다. 무상태 프로토콜이란 상태를 유지하지 않는 프로토콜이다. 즉 http의 태생상 상태관리가 되지 않기 때문에 서버에서는 조금 귀찮은 방법으로 상태관리를 해야 한다는 것.
  * 쿠키를 이용하는 방법, 세션을 이용하는 방법은 각각이 `cookies`, `session` 이라는 메서드를 이용한다.
* 필터
  * 필터란 액션 메서드가 실행되기 이전과 이후에 부가 처리를 위해 사용되는 기능이다.
  * 이전에 `모델`을 학습할 때는 DB관련 작업 전후 처리를 하기 위해 `callBack` 이라는 기능이 있었던 것처럼 컨트롤러에는 `필터` 기능이 있다.
  * 필터는 상속이 가능하다.
  * 모든 컨트롤러는 `ApplicationController` 를 상속 받는다. 따라서 모든 컨트롤러에서 사용하고 싶다? 이 `Application` 에다가 필터를 만들어 주면 된다.
  * 어떤 메서드에만 필터를 적용하고, 적용하지 않을 수 있는 기능이 있다. `only` 와 `except` 를 이용하면 된다.
* 라우팅
  * RESTful 인터페이스는 REST의 특징을 가진 라우트를 말한다. REST는 네트워크의 모든 컨텐츠를 URL로 표현하는 것이다. 그리고 이러한 URL에 HTTP, GET, POST, PATCH DELETE 등의 방법으로 접근한ㄷ. 한마디로 REST는 무엇(리소스)를 어떻게 (HTTP 메서드)할지 표현하는 것이다.
  * RESTful 인터페이스를 잘 사용하면 통일감 있고 의미가 명확한 URL 설계가 가능하다.
  * rails는 원칮걱으로 RESTful 인터페이스를 기반으로 라우트를 설계한다.
    * `form_with`, `link_to` 등의 뷰 헬퍼는 RESTful 인터페이스를 전제로 설계되었다.
  * RESTful 인터페이스를 정의할 때는 routes.rb 에서 `resources` 메서드를 호출하면 된다.
  * resources 는 CRUD 할 수 있는 정보라고 생각하면 된다.
    * 이렇게 생성하고 이후에 쉘에 `rails routes` 라고 명령을 입력하면 각 라우팅 정보가 나온다.
  * 복수말고 단수의 `resource`도 존재한다.
    * 이 메서드는 `하나의 리소스`를 관리하는 `RESTful` 인터페이스를 만들 수 있다.
    * 아직 실습해보지는 않았지만, 로그인 한 상태의 유저가 자신의 프로필을 보고 싶을 때, `/users/profile/user.id` 처럼 프로필 인덱스에서 자신의 `id`를 이용해 자기의 프로필을 찾는건 너무 멍청해 보인다.
    * 아마 이런 경우에 `resource` 를 사용하는게 아닌가 싶다.
  * `constrains` 기능으로 라우트매개 변수에 제약 조건을 걸 수 있다.
    * 제약은 기본적으로 모델, 컨트롤러 모든 곳에서 다 할수있다.
    * 그렇다면 어디서 이 제약을 거는게 좋은걸까?
  * `as` 를 이용해 `URL` 헬퍼 이름을 변경할 수 있다.
  * 중첩 구조를 이용할 수 있다. 가령 book 이라는 모델에는 reviews 가 has\_many, belongs\_to 로 묶여있다. 우리는 당연히 book과 관련된 URL으로 reviews를 찾아야 할 것이다 라고 생각한다. (`/books/:book_id/reviews`) 이렇게 해주고 싶을 때 사용하는게 중첩구조의 resources 다.
    * 이렇게 중첩으로 바꾸면 기존에 만들었던 뷰 들을 다 수정해야 한다.

### 7. 오늘 학습 내용에 대한 개인적인 총평

* 흠.. 오늘은 나쁘지 않게 학습한 것 같다. 내일은 더 열심히 해봐야겠다.

### 8. 다음 학습 계획

* 7장 복습, 회원가입, 로그인, 로그아웃 등의 기능이 있는 사이트를 간단하게 구조 생각하고 만들어보


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://simian114.gitbook.io/blog/undefined-1/diary/2020/12/20201229.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.