HTTP 메서드

URI 설계

URI (Uniform Resource Identifier) 를 설계하는 데 있어 가장 중요한 부분은 바로 리소스 식별 이다.

 

그렇다면 리소스란 무엇인가?

가령 회원에 대한 API 설계 시 회원을 등록하고 수정하는게 리소스가 아니다

회원이라는 개념 자체가 바로 리소스인 것이다.

 

다시 정리하자면, URI 는 리소스만 식별할 수 있도록 설계하며,

해당 리소스를 대상으로 하는 행위와는 분리시켜 설계하여야 한다.

 

그렇다면 행위는 어떻게 구분을 짓는가?

특정 리소스에 대한 행위는 HTTP 메서드를 통해 구분지을 수 있다.

 

HTTP 메서드 종류

• GET
• POST
• PUT
• PATCH
• DELETE
• HEAD
• OPTIONS
• CONNECT
• TRACE

GET

• 식별된 리소스 조회
• 서버에 요청하고자 하는 데이터는 Query(쿼리 파라미터, 쿼리 스트링)를 통해서 전달
• 메시지 바디를 사용해서 데이터를 전달할 수 있지만, 지원하지 않는 경우도 있기에 권장되는 방식은 아님

POST

• 클라이언트로부터 요청된 데이터 처리 메서드
• 메시지 바디를 통해 서버로 요청 데이터 전달하고 해당 서버는 요청 데이터를 처리
• 주로 전달된 데이터로 신규 리소스 등록, 프로세스에 사용한다.

POST 메서드의 경우 주로 신규 리소스 등록에서 많이 사용되지만,

가장 핵심 스펙은 요청된 데이터를 정해진 규칙에 따라 처리하는데 있다.

PUT

PUT 메서드의 경우 식별된 리소스를 대체한다.

• 리소스가 있으면 대체
• 리소스가 없으면 생성

여기서 주의 깊게 살펴볼 부분은 클라이언트가 리소스를 식별할 수 있다는 점이다.

즉 다시말해, POST 와는 다르게 클라이언트가 리소스 위치를 알고 URI 지정하는 것이다. 

/members/{id} - 식별된 리소스에 메서드 요청

PUT 메서드에선 리소스가 대체된다는 점을 유의깊게 살펴볼 필요가 있다.

10 번 member 데이터

위 그림 같이 식별된 리소스 데이터가 존재하는 경우, PUT 메서드 요청을 보내면 해당 리소스는 완전히 대체된다.

PUT 요청 예시

기존 member 10 에 있던 name 필드가 사라지고 요청된 데이터로 완전히 기존 리소스가 대체된다.

이때 만약 기존 리소스가 없었다면 요청된 데이터로 새롭게 생성하여 응답한다.

PATCH

PATCH 메서드는 리소스를 부분 변경하는 메서드이다.

10 번 member 데이터

위 그림 같이 식별된 리소스 데이터가 존재하는 경우,

PATCH 메서드 요청을 보내면 해당 리소스의 부분을 변경할 수 있다.

PATH 요청 예시

기존 member 10 이란 식별된 리소스는 그대로 존재하며, age 필드만 새로운 값으로 대체되어 응답된다.

 

이외 HTTP 메서드 역할

• DELETE: 식별된 리소스 삭제
• HEAD: GET 과 동일하지만 메시지 부분을 제외하고, 상태 줄과 헤더만 반환
• OPTION: 대상 리소스에 대한 통신 기능 옵션를 설명 (주로 CORS 에서 사용)
• CONNECT: 대상 자원으로 식별되는 서버에 대한 터널을 설정
• TRACE: 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행

 

HTTP 메서드 속성

• Safe
• Idempotent
• Cacheable

HTTP 메서드 별 속성 - https://ko.wikipedia.org/wiki/HTTP

안전 Safe

메서드를 호출하여도 리소스를 변경하지 않는다

• GET
• HEAD
• OPTIONS
• TRACE

로그 나 어떤 외부요인에 의한 장애는 고려하지 않고 오로지 해당 리소스만 고려한다.

멱등 Idempotent

메소드를 몇번을 호출하여도 항상 결과가 동일하다.

• GET - 몇번을 조회하여도 같은 결과가 조회된다.
• PUT - 리소스를 완전히 대체하기에, 같은 요청을 여러번 해도 최종 결과는 항상 동일하다.
• DELETE - 결과를 삭제하기에 요청을 여러번 하여도 삭제된 결과는 똑같다.

멱등 속성은 자동 복구 메커니즘에서 사용된다.

 

서버가 장애가 발생하여 정상 응답을 주지 못한 경우,

클라이언트가 같은 요청을 다시 해도 되는가 등의 판단 근거로서 활용된다.

 

이외에 리소스가 중간에 바뀌는 등의 외부요인을 고려하지 않는다.

동일한 사용자가 동일한 요청을 여러번하는 경우만을 고려한다.

캐시가능 Cachable

응답된 결과를 캐시해서 사용되는지 여부

• GET
• HEAD
• POST
• PATCH

실제 사용 시엔 GET, HEAD 정도만 캐시하여 사용한다.

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

 

참고

• 해당 게시글은 김영한 님의 "모든 개발자를 위한 HTTP 웹 기본 지식" 을 참고하여 작성하였습니다.
• 보다 자세한 내용은 강의를 통해 확인하시는 걸 적극 권장 드립니다.