[Network] 05. HTTP 메서드

해당 글은 김영한님의 모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 | 강의를 수강하고 정리한 게시글입니다.

HTTP 메서드

이번에는 HTTP 메서드를 알아보고 어떤게 좋은 API URI인지 알아보자.
우리가 생각했을 때 코드의 이름처럼 행위들에 이름을 구분하기 쉽게 길게 짓는게 좋아보일 수 있다.

 

[예시] :

• 회원 목록 조회 /read-member-list
• 회원 조회 /read-member-by-id
• 회원 등록 /create-member …

 

그러나, 위의 예시들은 좋은 URI 설계가 아니다.
그럼 어떻게 설계하는게 좋을까? 바로 리소스 식별방식으로 설계하는게 좋다. (URI는 리소스만 식별하도록)

 

그렇다면 리소스의 의미는 무엇일까? (회원을 등록하고 수정하고 조회하는 행위는 리소스가 아니다..)
리소스는 회원이라는 개념 자체가 리소스이다. (리소스: 회원, 행위: 등록, 수정, 조회)

 

즉, 우리가 생각하는 메서드에서 리소스를 식별하고 리소스와 행위를 분리하는 것이 중요하다.

그렇다면, 이렇게 분리하고 어떻게 URI를 설계하면 되나..

 

[예시] :

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

참고 : 계층 구조상 상위를 컬랙션으로 보고 복수 단어 사용 권장 (member보다는 members)

위의 예시의 URI를 보면 회원 목록 조회를 제외하고는 모두 동일하다..?!
그럼 어떻게 구분할 수 있는 것일까.. 바로 이번에 알아볼 HTTP 메서드를 사용하면 구분될 수 있다.

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

GET

리소스 조회용으로 사용하는 메서드
서버에 전달하고 싶은 데이터는 query(쿼리 파라미터)를 통해서 전달
메시지 바디를 사용해서 데이터를 전달할 수 도 있다(지원하지 않는 곳이 많아서 권장X)

예시

1. 메시지 전달

클라이언트에서 HTTP 요청메시지를 그림과 같이 보낸다.
(의미는 GET방식으로 /members/100을 원한다. )

HTTP 메시지의 자세한 내용은 다음 참고[Network] 04. HTTP 메시지

 

2. 서버 도착

서버에 클라이언트 요청메시지가 정상 도착

 

3. 응답 데이터

응답 메시지로 그림과 같이 받을 수 있다.
(의미는 HTTP1.1버전과 상태코드 200 성공 및 메시지 바디 부분)

POST

Post는 메시지 바디를 통해 서버로 요청 데이터를 전달한다. 서버는 메시지 바디를 통해 들어온 데이터를 처리하는 모든 기능을 할 수 있고 주로 전달된 데이터로 신규 리소스 등록이나 프로세스 처리에 사용한다.
(조회용으로 POST를 쓰면 캐시같은걸 못쓰기때문에 비효율적일 수 있다.)

예시

1. 메시지 전달

클라이언트에서 HTTP 요청메시지를 그림과 같이 보낸다.

 

2. 신규 리소스 생성

서버쪽에서 메시지 바디의 데이터 부분으로 새로운 리소스를 등록하고 식별자를 생성한다.(서버에서 신규 URI를 결정하고 만듬)

 

3. 응답 데이터

응답 메시지로 생성을 알리고 신규 URI가 등록된걸 알 수 있다.

요청 데이터를 어떻게 처리하는 것일까?
리소스 URI에 POST 요청이 오면 요청 데이터를 어떻게 처리할지 리소스마다 따로 정해야 함. (즉, 정해진 것이 없음)

POST 기능 정리

1. 새 리소스 생성(등록)
   서버가 아직 식별하지 않은 새 리소스 생성
2. 요청 데이터 처리
   단순히 데이터를 생성하거나, 변경하는 것을 넘어서 프로세스를 처리해야 하는 경우
   • 예) 주문에서 결제완료 -> 배달시작 -> 배달완료 처럼 단순히 값 변경을 넘어 프로세스의 상태가 변경되는 경우
     POST의 결과로 새로운 리소스가 생성되지 않을 수도 있음
   • 예) POST /orders/{orderId}/start-delivery (컨트롤URI)
3. 다른 메서드로 처리하기 애매한 경우 사용
   • 예) JSON으로 조회 데이터를 넘겨야 하는데, GET 메서드를 사용하기 어려운 경우
     애매하면 POST로 처리하면 된다.

PUT

PUT은 폴더에 파일을 넣는거와 비슷하다(있으면 교체, 없으면 생성) 즉, 덮어 버리는것과 같다. (그래서 변경할 때 빠진 필드가 있는지 주의해야한다.)

POST와 차이는 클라이언트가 리소스 위치를 정확히 알고 URI를 지정한다

예시

리소스가 있는 경우

PUT 방식으로 URI를 지정해서 서버에 요청 메시지를 보낸다.

 

서버에 있는 기존 리소스를 요청 메시지의 리소스로 덮어버린다.
(이때, 주의할 점은 username이나 age가 빠지면 해당 필드가 빠진채로 덮어진다.)

리소스가 없는 경우

PUT 방식으로 URI를 지정해서 서버에 요청 메시지를 보낸다. 그러나 이번에는 서버에 해당 리소스가 없다.

 

서버에 해당 리소스가 없기 때문에 이번에는 서버에서 해당 리소스(100번)에 새로 리소스를 생성한다.

PATCH

PATCH는 PUT과 달리 덮어쓰지 않고 변경하고 싶은 부분만 데이터로 보내면 부분 변경이 가능하다.

예시

클라이언트에서 변경하고 싶은 필드만 값을 넣어서 서버로 요청한다.

 

해당 필드(age)만 서버에서 변경된다.

DELETE

제거하고 싶은 리소스를 지정(URI 지정)해서 제거한다.

에시

클라이언트에서 리소스를 지정해서 서버에 DELETE 메서드를 보낸다.

 

서버에서 해당 리소스를 제거한다.

HTTP 메서드의 속성

HTTP 메서드에는 안전, 멱등, 캐시가능등 여러 속성을 가지는데 먼저 속성에 대해 알아보고 메소드들이 해당 속성을 가지는지 표로 알아보자.

안전(Safe Methods)

안전은 메소드를 계속 호출해도 리소스를 변경하지 않는 걸 의미한다.
GET을 생각해보면 해당 리소스를 불러오기만하기 때문에 리소스 변경의 여지가 없다.

참고 :
로그 같은게 쌓여서 장애가 발생하면? 안전은 해당 리소스만 고려하고 그런 세세한 부분까지는 고려하지 않는다.)

멱등(Idempotent Methods)

한 번 호출하든 여러번 호출하든 결과가 항상 같다. ( f(f(x)) = f(x)를 의미)
GET, PUT등을 생각해보면 같은 요청 메시지를 보내면 항상 같은 응답 메시지로 리소스가 동일한 걸 알 수 있다.

 

[멱등 메서드 예시] :

• GET: 한 번 조회하든, 두 번 조회하든 같은 결과가 조회된다.
• PUT: 결과를 대체한다. 따라서 같은 요청을 여러번 해도 최종 결과는 같다.
• DELETE: 결과를 삭제한다. 같은 요청을 여러번 해도 삭제된 결과는 똑같다.
• POST: 멱등이 아니다! 두 번 호출하면 같은 결제가 중복해서 발생할 수 있다.

이를 어디에 활용할 수 있을까?

• 자동 복구 메커니즘
• 서버가 TIMEOUT 등으로 정상 응답을 못주었을 때, 클라이언트가 같은 요청을 다시 해 도 되는가? 판단 근거가 될 수 있다. (결제같은 경우는 2번 결제가 되면 안되지만, 게시물 수정같은 경우는 상관 없다.)

참고:
재요청 중간에 다른 곳에서 리소스를 변경해버리면?
멱등은 외부 요인으로 중간에 리소스가 변경되는 것 까지는 고려하지 않는다.

캐시가능(Cacheable Methods)

응답 결과 리소스를 캐시해서 사용해도 되는가를 의미한다.
GET, HEAD, POST, PATCH 등이 캐시가능하지만, 실제로는 GET, HEAD (GET과 동일하지만 메시지 부분을 제외하고, 상태 줄과 헤더만 반환)정도만 캐시로 사용한다.

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

속성 정리 표

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

 

이렇게 HTTP 메서드들에 대해 알아보고 메서드의 속성들도 간단히 알아보았다. 

다음에는 이를 활용해서 어떻게 설계하면 좋을지 예시와 함께 알아보도록 하자.