[WEB/HTTP] 04. HTTP 메서드

 

 

이 글은 인프런 강의 "모든 개발자를 위한 HTTP 웹 기본 지식" 을 학습하며 정리한 내용입니다.

저처럼 HTTP를 알고 싶거나, 겉핥기로 알고 있는 분들에게 위 강의를 추천합니다.

 

정리한 내용 중 틀린 내용이 있으면 지적해주시면 수정하겠습니다.

---

1. HTTP API를 만들어보자.

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

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

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

회원 등록 : /create-member

회원 수정 : /update-member

회원 삭제 : /delete-memebr

 

위와 같은 API URI 설계는 좋은 방법이 아니다.

API URI 설계 시 가장 중요한 것은 리소스 식별이다.

 

여기서 리소스란, 회원이라는 개념 자체가 바로 리소스이다.

회원을 등록, 수정 등 행위하는 것은 생각하지 않고 대상이 되는 자원.

즉, 회원 리소스만 식별하면 된다.

 

회원 목록 조회 : /members

회원 조회 : /members/{id}

회원 등록 : /members/{id}

회원 수정 : /members/{id}

회원 삭제 : /members/{id}

 

회원을 리소스로 식별하고, URI 계층 구조를 활용하여 설계한 방식이다.

복수 단어의 사용을 권장한다. (member > members)

 

리소스와 행위를 분리

URI는 리소스만 식별한다.

대상이 되는 리소스와, 리소스를 대상으로 하는 행위를 분리해야 한다.

 

리소스 : 회원 (명사)

행위 : 조회, 등록, 삭제, 변경 (동사)

 

위 API URI 설계에서 회원 조회, 등록, 수정, 삭제 모두 같은 URI를 나타낸다.

하지만 각각 다른 행위를 의미하고 있는데 이 행위는 어떻게 구분할까? ->  HTTP 메서드

---

2. HTTP 메서드 - GET, POST

• HTTP 주요 메서드 종류

GET	리소스 조회
POST	요청 데이터 처리, 주로 등록에 사용
PUT	리소스를 대체, 해당 리소스가 없다면 생성
PATCH	리소스 부분 변경
DELETE	리소스 삭제

 

• GET

리소스 조회에 사용서버에 전달하고 싶은 데이터는 query(쿼리 파라미터, 쿼리 스트링)을 통해서 전달

메시지 바디를 사용하여 전달할 수 있지만 권장하지 않음

 

• POST

요청 데이터를 처리메시지 바디를 통해 요청 데이터 전달 (GET은 쿼리 스트링으로 했었음)

데이터를 처리하는 모든 기능을 수행하고, 주로 신규 리소스 등록 및 프로세스 처리에 사용

 

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

GET은 조회라는 아주 명확한 목적이 있는 반면에, POST는 조금 넓은 개념

 

새 리소스를 생성(등록)만 하는 용도로 POST로 알고 있었는데 그게 아니었다.

요청 데이터 처리도 POST로 이뤄짐, 프로세스의 상태가 변경되는 처리를 하는 경우 POST로 처리

 

2. 요청 데이터 처리

예) 결제완료 -> 배달시작

단순히 하나의 주문의 현재 상태 값을 변경하는 것을 넘어 프로세스의 상태가 변경되는 중요한 처리

이 경우 POST의 결과물로 신규 리소스가 생성이 안될 수 있음

 

API URI 설계 시 리소스를 식별하여 명사형으로 설계하는 게 이상적이지만, 현실은 힘듦

필요에 따라 동사형을 사용하여 URI를 설계하는데 이를 컨트롤 URI 라고 부름

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

 

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

JSON으로 조회 데이터를 넘겨야 하는데..

조회 시 사용하는 GET 메서드도 메시지 바디를 사용할 순 있지만, 권장하지 않음

 

즉, 애매하면 POST 메서드 사용 ! 만능 느낌..

---

3. HTTP 메서드 - PUT, PATCH, DELETE

• PUT

리소스를 완전히 대체

있으면 대체(덮어 쓰기)

없으면 생성

 

클라이언트가 리소스를 식별

클라이언트에서 이미 리소스의 위치를 지정한 상태에서 요청함

예) 100번 회원을 미리 지정하고 데이터를 전송하여 대체

POST와의 차이점 : POST는 몇 번째 회원을 등록하는지 지정하지 않음

 

완전히 대체

100번 회원의 이름, 나이 정보가 있다. { name = 'gildong', age = '20' }

PUT /members/100 { age = '35' } 로 PUT 요청이 온다면?

 

{ age = '35' } 로 변경

나이 정보만 수정되는 것이 아니라 나이 정보만 남음. 즉, 완전히 대체 (덮어 써버림)

 

그렇다면 나이 정보만 수정하고 싶을 때는..?

리소스의 일부분만 변경하고 싶을 때는..?   > PATCH 메서드

 

• PATCH

리소스 부분 변경

위에서 설명한 대로 PATCH 메서드는 부분 변경 행위를 한다.

 

100번 리소스 : { name = 'gildong', age = '20' }

PATCH /members/100 { age = '30' }

{ name = 'gildong', age = '30' }

 

이렇게 이름은 유지되고, 나이만 변경된다.

 

• DELETE

리소스 제거

---

4. HTTP 메서드의 속성

• 안전(Safe Methods) - GET

호출해도 리소스를 변경하지 않는다.

즉, 100번 호출해도 리소스를 변경하지 않기 때문에 안전한 메서드로 분류

 

GET 이외의 메서드들은 리소스 변경이 가능하므로 안전하지 않는 메서드

 

• 멱등(Idempotent) - GET, PUT, DELETE

한 사용자가 한 번 호출하든, 두 번 호출하든, 100번 호출하든 결과가 똑같다.

 

GET : 한 번 조회하든, 두 번 조회하든 같다.

PUT : 완전히 대체한다. 처음 호출한 요청과 마지막에 호출한 요청의 결과는 같다

DELETE : 삭제한다. 여러 번 호출해도 삭제된 결과는 같다

POST : 멱등이 아니다! 두 번 호출하면 같은 데이터(결제)가 중복해서 발생될 수 있다.

 

멱등은 자동 복구 메커니즘에 활용

GET, PUT, DELETE 를 서버에 요청한 뒤 TIMEOUT 등으로 응답이 클라이언트에 오지 않았을 때

클라이언트가 같은 요청을 서버에 보낼 수 있는 판단 근거가 됨

 

즉, 멱등 메서드이면 다시 호출해도 결과는 같기 때문에 재호출해도 무방한 요청임을 의미

 

• 캐시 가능(Cacheable) - GET, HEAD, POST, PATCH

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

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

 

 

웹 브라우저에 용량이 큰 이미지를 한 번 요청하면, 그 뒤에 웹 브라우저 내부에 저장하여 사용하는 방식이 캐시

캐시를 사용하지 않으면, 용량이 큰 이미지를 요청할 때마다 서버에서 다운로드하려면 속도가 느림

 

출처 : https://ko.wikipedia.org/wiki/HTTP