Section 2 - Unit 5 : [네트워크] HTTP Review

Review 에서는 학습한 내용을 다시금 기록합니다.
Unit Review는 학습한 내용 중 기존에 알고 있었지만 정확하게 이해하지 못하던 정보와 새롭게 알게된 정보를 기록합니다. 추가적인 설명을 요하는 부분은 댓글로 남겨주세요.
Section Review는 전반적인 Section을 되돌아보고 학습했던 시간과 과정, 내용을 총괄하여 기록합니다.

REST API

* REST API

- REST API란?

• HTTP 프로토콜을 통해 클라이언트 - 서버 간 통신을 하기 위해서는 HTTP 메서드를 이용해야한다. 예를 들어, GET으로 데이터를 요청하거나 POST를 사용해 데이터를 추가하고 PUT을 통해 데이터를 업데이트한다.
• 그런데, 이러한 일련의 과정을 서비스마다 마음대로 한다면 어떻게 될까? 아마 개발자들의 이직은 꿈도 못 꿀 것이다. 새로운 회사에 입사하면, 그 회사의 HTTP 메서드 사용 규약부터 다시 익혀야하기 때문이다.
• 또한, 다른 이들은 도대체 내가 짠 HTTP request가 무엇을 의미하는지 알기 어려울 것이다. 이는 서비스를 제공하는 하나의 집단 내에서도 소통을 어렵게 만든다. 
• 이러한 문제를 해결하기 위해 제시된 것이 로이 필딩의 REST API 방법론이다.
• REST API는 웹에서 사용될 데이터나 자원은 HTTP URI로 표현하고, HTTP 메서드를 통해 통신하는 방식을 말한다.

- 좋은 REST API를 디자인하는 방법

• 그렇다면, HTTP를 Restuful하게 작성하기 위해서는 어떻게 작성해야할까. 로이 필딩은 REST API를 잘 적용하기 위한 4단계 모델을 제시한다.
• 0단계~ 3단계까지 이루어진 해당 모델을 모두 충족시키기는 어렵다. 2단계까지만 충족시켜도 좋은 API 디자인이라고 볼 수 있다.

- REST 성숙도 모델 0 단계

• HTTP 프로토콜을 사용하기만 하면 된다. 이는 좋은 REST API를 작성하기 위한 기본 단계다.
• 어떤 HTTP 메서드를 쓰는지 신경쓰지 않고(일반적으로 POST를 사용한다) Single URI를 사용한다.
• 아래의 예시를 통해 살펴보자.

• 예약 가능한 시간을 '확인' 하는데도 POST를 쓰고 있다.
• 서로 다른 요청을 /appointment 의 하나의 URI가 담당하고 있다.

- REST 성숙도 모델 1 단계

• 0단계에서 URI만 적절하게 사용하면 된다. 아래 예시를 통해 살펴보자.

• 여전히 POST 메서드를 통해 예약 가능 시간을 확인하고 있다.
• 그러나 URI가 달라졌다. 예약 가능한 시간을 확인하기 위해서 /doctors/허준 URI를 이용하고 있다. 예약을 위해서는 /slot/123을 사용하고 있다.
• URI만으로도 '허준이라는 의사'의 데이터와, '123번 슬롯'의 데이터에 무언가 할 것임을 알 수 있다.
• URI를 작성할 때는 동사의 사용을 지양하자. URI는 말 그대로 데이터 자원을 식별하는 식별자다. 즉, 자원 그 자체에 집중한다. 자원이 움직이지는 않잖아? 자원이라는 이름에 걸맞게, 명사 형태를 이용해 URI를 작성하자.
• 또한, response에는 request의 수행이 성공했는지 실패했는지 여부를 함께 담아 반환해야 한다. 예를 들어, 위의 예시에서 예약이 실패하면 아래 예시와 같이 상태는 409 Conflict를, body에 실패 정보를 담아서 반환해야한다.

- REST 성숙도 모델 2단계

• 1단계에 더해 HTTP 메서드를 CRUD에 맞게 적절히 사용한다. 아래 예시를 통해 살펴보자.

• 드디어 예약 가능 시간을 확인하기 위해 GET 메서드를 사용했다.
• GET 메서드에도 body를 담을 수는 있으나, 담지 않는 것을 원칙으로 한다. 따라서 read(GET)의 조건을 담을 부분은 URI의 query를 이용하여 전달한다.
• 예약을 create(POST)한 결과에 대한 응답은 명확하게 201 Created로 전달되어야 한다. 또한 status line에 Location 정보를 포함해 작성된 URI정보를 확인할 수 있어야 한다.
  • 메서드 사용 규칙
    • GET : 서버의 데이터를 변화시키지 않는 요청
    • POST : 요청마다 새로운 리소스 생성. -> 완전히 새로운 데이터의 삽입
    • PUT : 요청마다 같은 리소스 반환. -> 기존 데이터의 교
      • POST vs PUT : post는 아예 새로운 데이터를 삽입할 때 쓴다면, put은 기존의 데이터를 새롭게 바꿀 때 쓴다고 생각하면 편하다. 해시 자료구조를 사용하는 녀석들의 add를 생각해보자. add로도 데이터를 교체할 수 있지만 우리는 replace를 쓴다.
    • PATCH : 데이터를 수정하는 용도
      • PUT vs PATCH : put은 데이터 자체를 새로운 데이터로 교체하고 patch는 데이터의 일부를 바꾼다.
        put은 replace, patch는 update 쿼리의 역할을 한다고 이해하면 편하다.
    • 나머지 메서드들은 용도에 맞게 쓰면 된다.

- REST 성숙도 모델 3단계

• 3단계는 2단계까지의 과정에 HATEOAS라는 하이퍼미디어 컨트롤을 적용한다.
• HATEOAS(Hypertext As The Engine Of Application State)는 Hypermedia (링크)를 통해서 애플리케이션의 상태 전이가 가능해야 하며, 또한 Hypermedia (링크)에 자기 자신에 대한 정보가 담겨야 함을 의미한다.
• 즉, response body에는 내가 request한 데이터를 담은 링크와, 내 request를 통해 연쇄적으로 할 수 있는 일들에 대한 링크가 담겨있어야 한다는 뜻이다.
• 아래 예시를 통해 살펴보자.

• 예약 가능한 시간을 확인하고 싶다고 request하자, response에는 예약 가능한 시간 데이터에 예약을 할 수 있는 링크까지 담아서 전송하고 있다.
• 예약을 한다고 request하자, 해당 예약을 확인할 수 있는 링크와 예약을 취소할 수 있는 링크까지 담아서 전송하고 있다.