[모든 개발자를 위한 HTTP 웹 기본 지식] 4. HTTP method

HTTP 만들어보기

요구사항: 회원 정보 관리 API를 만들어보자.

사실 진짜 백엔드의 API를 설계하는 것은 아니고, 개념적으로 설계해보자는 의미이다.

 

기능 요구 사항

• 회원 목록 조회
• 회원 조회
• 회원 등록
• 회원 수정
• 회원 삭제

기능에 따른 API URI 설계

• 회원 목록 조회 /read-member-list
• 회원 조회 /read-member-by-id
• 회원 등록 /create-member
• 회원 수정 /update-member
• 회원 삭제 /delete-member

이게 정말 좋은 URI 설계일까? (X)

 

 API의 URI(Uniform Resouce Identifier)를 설계하면서 고민해야 할 사항들

• resource의 의미?
  • 회원 등록, 수정, 조회가 리소스가 아니다!
  • 회원이라는 개념 자체가 바로 리소스
• resource를 어떻게 식별하는 것이 좋을까?
  • 회원을 등록하고 수정하고 조회하는 것을 모두 배제한다.
  • 회원이라는 리소스를 식별하는 것에 집중!, 따라서 회원 리소스를 URI에 매핑한다.

API URI를 다시 설계해보자.

여기서는 리소스 식별에 집중하자는 점과 URI 계층 구조를 활용하자는 점을 반영해보자.

• 회원 목록 조회 /members
• 회원 조회 /members/{id}
• 회원 등록 /members/{id}
• 회원 수정 /members/{id}
• 회원 삭제 /members/{id}

회원은 여러 명이 존재하기 때문에, 복수형으로 표현하고 계층 구조를 적용해 members 다음에 회원 id를 배치해보자.

하지만 여기에서는 조회, 등록, 수정, 삭제 기능을 URI 만으로 구별할 수 없다는 문제가 발생한다.

 

리소스와 행위를 분리하자.

• URI는 리소스 식별에만 집중
• 리소스와 해당 리소스를 대상으로하는 행위를 분리하자!
  • 리소스: 회원
  • 행위: 조회, 등록, 삭제, 수정..
• 리소스는 명사, 행위는 동사
• 그렇다면 행위(메서드)는 어떻게 구분할까

이제 다음 단계부터 행위를 구분하기 위해 사용하는 HTTP method에 대해서 정리해보자.

---

HTTP method - GET, POST

HTTP method 종류 정리

• GET: 리소스 조회
• POST: 요청 데이터 처리, 주로 등록에 사용한다.
• PUT: 리소스 전체를 대체, 해당 리소스가 없는 경우 생성
• PATCH: 리소스의 일부를 변경
• DELETE: 리소스 삭제
• 기타
• HEAD: GET과 동일하지만 HTTP message의 body부분을 제외하고, header와 status line만 반환
• OPTIONS: 대상 리소스에 대한 통신 가능 옵션을 설명 (주로 CORS에서 사용된다고..)
• CONNECT, TRACE: 이 두가지는 거의 사용되지 않는다고 한다..

최근에는 Resource가 아니라 Representation이라는 개념으로 대체되었다고 한다.

 

GET

• 리소스를 조회하는 method
• 서버에 전달하고 싶은 데이터를 query(쿼리 파라미터, 쿼리 스트링)을 통해 전달한다.
• 메시지 바디를 이용할 수 있지만, 지원하지 않는 곳이 많아 권장하지 않는다고 한다.

HTTP method를 이용한 리소스 조회 과정

1. client에서 server로 request message를 전달
2. message가 server에 도착
3. server에서 client로 response message를 전달

 

POST

• 요청 데이터를 처리하는 method
• message body를 통해 server로 request data를 전달한다.
• server는 request data를 처리
  • message body 파트를 통해 들어온 데이터를 처리하는 모든 기능을 수행한다.
• 주로 전달된 데이터를 이용해 신규 리소스 등록, 프로세스 처리 과정을 진행한다.

 POST method 또한 큰 틀에서 GET method와 유사하게 동작하는데, 미리 약속된 URL로 POST method에 따른 message를 전달하면, message body에 실려온 데이터를 이용해 자원을 추가한다던가 특정 process를 수행하는 등의 작업을 진행하게 된다. (주로 POST는 resource 추가를 진행)

 

요청 데이터를 어떻게 처리한다는 뜻일까? 예시

• 스펙: POST method는 대상 리소스가 리소스의 고유한 의미 체계에 따라 요청에 포함된 표현을 처리하도록 요청합니다. (번역 결과)
• 예를 들어 POST는 다음과 같은 기능 구현을 위해 사용한다고 함
  • HTML 양식에 따라 입력된 필드와 같은 데이터 블록을 데이터 처리 프로세스에 제공
    • 예) HTML form에 입력한 정보로 회원 가입, 주문 등에 사용
  • 게시판, 뉴스 그룹, 메일링 리스트, 블로그 또는 유사한 기사 그룹에 메시지 게시
    • 예) 게시판 글쓰기, 댓글 달기
  • 서버가 아직 식별하지 않은 새로운 리소스 생성
    • 예) 신규 주문 생성
  • 기존 자원에 데이터 추가
    • 예) 한 문서의 끝에 내용을 추가하기
• summary: 이 리소스 URI에 POST request가 들어오면, 요청 데이터를 어떻게 처리할지에 대해 리소스마다 따로 정의해야 한다. > 정해진 동작 없이 원하는 대로 지정이 가능하다.

POST 정리

• 1. 새로운 리소스 생성(등록)
  • 서버가 아직 식별하지 않은 새로운 리소스를 생성
• 2. 요청 데이터 처리
  • 단순히 데이터를 생성하거나, 변경하는 것을 넘어 새로운 프로세스를 처리하는 경우
  • 예) 주문에서 결제 완료 -> 배달 시작 -> 배달 완료 처럼 단순 값 변경을 넘어 프로세스의 상태가 변경되는 경우
  • POST의 결과로 새로운 리소스가 생성되지 않을 수도 있다.
  • 예) POST /orders/{orderId}/start-delivery (컨트롤 URI라고 부른다.)
  • 최대한 자원을 계층화해서 표현하려 하지만, 동사를 URI 설계에 포함할 수밖에 없는 경우가 발생하고, 이를 control URI라 부른다. 보통 컨트롤 URI는 POST method로 처리한다.
• 3. 다른 메서드로 처리하기 애매한 경우 사용
  • 예) JSON으로 조회 데이터를 넘겨야 하는데, GET method를 사용하기 어려운 경우
  • 애매하면 POST를 사용하자.

---

HTTP method - PUT, PATCH, DELETE

PUT

• 리소스를 완전히 대체한다.
  • 이미 존재하는 리소스는 대체
  • 존재하지 않는 리소스의 경우 새롭게 생성
  • 쉽게 이야기해서 덮어버린다.
• 중요! 클라이언트가 리소스를 식별한다!
  • 클라이언트가 리소스의 위치를 아는 상황에서 지정한 URI(URL)
  • POST와는 이미 존재하는 리소스를 덮어씌운다는 점에서 차이가 있다.

이미 존재하는 리소스에 클라이언트가 PUT method를 이용한 request를 보내는 경우 덮어씌운다.

리소스가 없는 경우에는 POST와 같은 방식으로 동작하여 새로운 리소스를 생성하게 된다.

 

PUT은 리소스를 제공된 정보를 바탕으로 완전히 대체하기 때문에, 기존에 리소스에 저장된 정보는 모두 사라지게 되고, 이는 제공하지 않은 필드에 대해서는 삭제함을 의미한다.

 

이러한 부분을 보완하기 위해 부분 수정을 대상으로는 PATCH method를 사용한다.

 

PATCH

PUT method와는 다르게 리소스를 부분적으로 대체한다.

 

위와 같이 제공되지 않은 필드의 정보는 유지한다.

DELETE

리소스를 제거하기 위해 사용하는 method

당연히 클라이언트가 리소스의 위치를 알고 있는 상황에서 DELETE method를 사용해 request를 보낼 것이다.

---

HTTP method의 속성

HTTP method는 다음과 같은 명칭들로 속성에 대한 정의가 가능하다.

• 안전 (Safe Methods)
• 멱등 (Idempotent Methods)
• 캐시 가능 (Cacheable Methods)

위키백과에 나와있는 HTTP method 속성 표는 위와 같이 정의되어 있다.

안전 (Safe Methods)

• 호출해도 리소스를 변경하지 않는 method를 정의하는 속성
• 이런 문제들은 여기 선에서 다루지 않는다.
  • Q: 아무리 리소스 변경이 없어도, 계속 호출해서 로그가 쌓여 오류가 발생해도 안전하다고 판단하나요?
  • A: 안전 속성은 해당 리소스만 고려한다. 그런 부분까지는 고려 X

멱등 (Idempotent Methods)

멱등이라는 말 자체가 익숙하지 않기 때문에, 이 말이 무엇인지 간략히 정리하면, 계속 호출해도 결과가 똑같은 method를 정의하는 개념이다.

• f(f(x)) = f(x)라고 설명되어 있으나, f(x), (fx), f(x) 후의 DB == f(x) 후의 DB 가 조금 더 어울리는 것 같다.
• 결국 위 수식이 설명하고자 하는 바는, 한 번 호출하든 여러 번 호출하든 결과가 같음을 의미한다. 
• 멱등 메서드
  • GET: 한 번 조회하든, 여러 번 조회하든 결과는 똑같다 (당연)
  • PUT: 결과를 대체하는 메서드, 따라서 같은 요청을 여러 번 보내도 결과는 같다.
  • DELETE: 리소스를 삭제하는 메서드, 여러번 요청을 보내더라도 한 번만 삭제될 것이다.
  • POST(X): 멱등이 아님!! 두 번 호출하면 같은 process가 중복해서 발생이 가능하다. (예를 들어 결제 프로세스)
• 멱등이라는 속성을 어디에 활용?
  • 자동 복구 메커니즘
  • 서버가 TIMEOUT 등으로 정상 응답을 못한 경우, 클라이언트가 같은 요청을 다시 해도 되는지에 대한 판단의 근거로 삼을 수 있다.

이런 경우에는 멱등이 아닌 것 같은데?

• Q: 재요청 중간에 다른 곳에서 리소스를 변경하면?
  • 사용자1: GET -> username: A, age: 20
  • 사용자2: PUT -> username: A, age: 30
  • 사용자1: GET -> username: A, age: 30
• A: 멱등은 외부 요인으로 중간에 리소스가 변경되는 것 까지는 고려하지 않고 판단하는 속성이다.

캐시 가능 (Cacheable Methods)

• 응답 결과 리소스를 캐시해서 사용해도 되는가?
• GET, HEAD, POST, PATCH는 가능하다고 함.
• 실제로는 GET, HEAD 정도만 캐시로 사용한다고 한다.
  • POST, PATCH는 본문 내용까지 캐시 키로 고려해야 하는데, 이는 구현이 까다롭기 때문이다.