[HTTP] HTTP 메서드

내가 공부한것을 올리며, 중요한 단원은 저 자신도 곱씹어 볼겸 상세히 기록하고 얕은부분들은 가겹게 포스팅 하겠습니다.

 

1. HTTP API를 만들어보자

우리에게 회원 목록 조회, 단일 회원 조회, 회원 등록, 회원 수정, 회원 삭제 기능을 갖는 API를 만들라고하면 URI를 어떻게 설계 해야할까?

 

아직 사전지식이 없다면 다음과 같은 형태를 생각할수 있다.

- 회원 목록 조회 /read-member-list

- 회원 조회 /read-member-by-id

- 회원 등록 /create-member

- 회원 수정 /update-member

- 회원 삭제 /delete-member

 

과연 좋은 설계라고 할수있을까?

설계의 핵심은 리소스 식별 이다!

 

● 그럼 과연 리소스는 뭘까?

회원을 등록하고, 수정하고, 삭제하는 행위는 리소스가 아니다, 회원 자체가 리소스다!

 

● 리소스를 어떻게 식별하는게 좋을까?

- 회원을 등록하고 수정하고 조회하는 것 등 행위를 모두 배제

- 회원이라는 리소스만 식별하면 된다. => 회원 리소스를 URI에 매핑

 

결과적으로 다음과 같은 형태를 나타낼 것 이다. 문제는 아직 행위를 어떻게 구별해야할지 모른다는 것이다.

출처 - 인프런 김영한 HTTP

● 리소스와 행위를 식별

- URI는 리소스만 식별!

- 리소스와 해당 리소스를 대상으로 하는 행위을 분리하자! ( 리소스 : 회원, 행위 : 조회, 등록, 삭제, 변경 )

리소스는 명사, 행위는 동사 (미네랄을 캐라) 행위(메서드)는 어떻게 구분할 것인가?

=> HTTP 메서드를 이용하면 된다!

 

2. GET, POST

● HTTP 주요 메서드 종류

- GET: 리소스 조회

- POST: 요청 데이터 처리, 주로 등록에 사용

- PUT: 리소스를 대체, 해당 리소스가 없으면 생성

- PATCH: 리소스 부분 변경

- DELETE: 리소스 삭제

 

● HTTP 기타 메서드 종류

- HEAD: GET과 동일하지만 메시지 부분을 제외하고, 상태 줄과 헤더만 반환

- OPTIONS: 대상 리소스에 대한 통신 가능 옵션(메서드)을 설명(주로 CORS에서 사용)

- CONNECT: 대상 자원으로 식별되는 서버에 대한 터널을 설정

- TRACE: 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행

 

● GET

get방식으로 서버에 전달할때는 보통 request-line과 헤더 부분만 이용한다. body는 거의 사용하지 않는다.

 

● POST

post방식은 메시지 body를 통하여 서버로 요청 데이터를 전달할수 있다. 메시지 body를 통하여 데이터를 전달받은 서버가 데이터를 처리하게 된다. 주된 전달 데이터로는 신규 등록하는 리소스, 프로세스 처리에 사용된다.

 

예를 들어 POST는 다음과 같은 기능에 사용될수 있습니다.

 

1) HTML 양식에 입력 된 필드와 같은 데이터 블록을 데이터 처리 프로세스에 제공

=> HTML FORM에 입력한 정보로 회원 가입, 주문 등에서 사용

 

2) 게시판, 뉴스 그룹, 메일링 리스트, 블로그 또는 유사한 기사 그룹에 메시지 게시

예) 게시판 글쓰기, 댓글 달기

 

3) 서버가 아직 식별하지 않은 새 리소스 생성

예) 신규 주문 생성

 

4) 기존 자원에 데이터 추가하기

예) 한 문서 끝에 내용 추가하기

 

정리: 이 리소스 URI에 POST 요청이 오면 요청 데이터를 어떻게 처리할지 리소스마다 따로 정해야 함 -> 정해진 것이 없음

 

● POST 정리

1. 새 리소스 생성(등록)

- 서버가 아직 식별하지 않은 새 리소스 생성할때 사용

 

2. 요청 데이터 처리

- 단순히 데이터를 생성하거나, 변경하는 것을 넘어서 프로세스를 처리해야 하는 경우

예) 주문에서 결제완료 -> 배달시작 -> 배달완료 처럼 단순히 값 변경을 넘어 프로세스의 상태가 변경되는 경우

 

- POST 결과로 새로운 리소스가 생성되지 않을 수도 있다.

위에서는 리소스 중심의 URI를 만들어야 한다고 했지만, 현실적으로 모든 부분에서 리소스만 갖고 URI를 설계하기는 매우 힘들다.

컨트롤 하는 행동도 포함되는데 이를 컨트롤 URI 라고 부른다.

예) POST /orders/{orderId}/start-delivery (컨트롤 URI)

 

3. 다른 메서드로 처리하기 애매한 경우

예) JSON으로 조회 데이터를 넘겨야 하는데, GET 메서드를 사용하기 어려운 경우 애매하면 POST

 

3. PUT, PATCH, DELETE

● PUT

put 방식은 기존의 리소스가 있다면 기존 리소스를 완전하게 대체하는 방식이다.

리소스가 없었다면 새로 생성해주지만, 만약 있다면 덮어씌워 버리는 무시무시한 방식이다.

또한 PUT을 사용하려면 클라이언트가 리소스의 위치를 알고 URI를 지정해야한다. 이는 POST와의 큰 차이점중 하나이다.

 

그림을 통해 확인해보자!

 

다음 그림을 보면 서버의 /members/100 에 이미 리소스가 있는 상황이다. 이러한 상황에서 PUT 메소드를 날리면 어떻게 될까?

출처 - 인프런 김영한 HTTP

다음 그림처럼 덮어씌워지는 것을 알수있다.

출처 - 인프런 김영한 HTTP

만약 위의 그림의 의도가 age만 50으로 바꾸려는 수정이 목적이였다면 이는 잘못된 결과가 나온것 이다.

이런 수정을 위한 메소드가 없을까? 바로 PATCH 이다!

 

● PATCH

리소스 부분 변경의 위한 메소드 이다. 다음 그림은 age만 변경된것을 알수있다.

출처 - 인프런 김영한 HTTP

● DELETE

삭제 메소드는 말 그대로 삭제하는 메소드이다.

 

4. HTTP 메서드의 속성

● 안전(Safe Methods)

호출해도 리소스를 변경하지 않는것을 말한다. (ex: GET, HEAD)

리소스의 변경이 일어나지 않는 것을 Safe하다고 표현한다.

 

● 멱등(Idempotent Methods)

몇 번을 호출하든 결과가 동일해야한다. => f(f(x)) = f(x)

 

멱등 메서드

- GET : 조회를 여러 번 해도 동일한 결과가 조회된다.

- PUT : 결과를 대체함. 같은 요청을 여러 번 수행해도 최종 결과는 같음

=> 맨 처음 PUT을 하면 기존의 리소스를 덮어씌우거나, 새로 생성한다. 이 상태를 y라고 하자.

이후 같은 PUT 요청을 하게되어 덮어씌우게 된다. 이 결과또한 y이다.

예를들어 int를 100으로 저장하라는 PUT 메소드가 있다면 처음 100으로 설정한후 여러번 호출해도 int값은 100으로 유지된다.

 

- DELETE : 삭제를 1번하든 100번하든 삭제된 결과는 같음

- POST : 멱등이 아니다! 결제가 2번 된다고 생각해보자!

 

단, 멱등은 외부 요인으로 중간에 리소스가 변경된 것을 고려하지 않음

사용자1: GET -> username:A, age:20

사용자2: PUT -> username:A, age:30

사용자1: GET -> username:A, age:30 -> 사용자2의 영향으로 바뀐 데이터 조회

 

멱등은 어떨 때 필요할까?

자동 복구 메커니즘

예를 들어, 클라이언트가 자원 삭제 요청을 했는데 서버가 응답이 없을 경우, 요청을 여러 번 해도 멱등하다는 것을 클라이언트가 인지하고 있으므로 DELETE 재요청할 수 있음. 판단의 근거가 됨

 

● 캐시가능(Cacheable Methods)

응답 결과 리소스를 캐시해서 사용해도 되는가?

GET, HEAD, POST, PATCH 캐시가능

실제로는 GET, HEAD 정도만 캐시로 사용

POST, PATCH는 본문 내용까지 캐시 키로 고려해야 하는데, 구현이 쉽지 않음