본문 바로가기
FrontEnd/HTTP

[HTTP] HTTP 메서드

by 개발 Blog 2024. 10. 6.

공부 내용을 정리하고 앞으로의 학습에 이해를 돕기 위해 작성합니다.

 

HTTP API

요구사항

회원 정보를 관리하는 API를 설계해야 한다. 다음과 같은 기능이 포함되어야 한다.

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

API URI 설계

URI(Uniform Resource Identifier)는 리소스를 식별하기 위한 고유 식별자다. 처음 설계된 URI는 다음과 같다.

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

리소스 식별

URI 설계에서 가장 중요한 것은 리소스 식별이다. 중요한 점은 회원이라는 개념 자체가 리소스라는 것이다.

회원을 등록하고 수정하고 조회하는 행위는 URI에서 드러내지 않아도 된다.

회원 등록, 수정, 조회 등의 동작을 URI에 넣는 것이 아니라, 회원이라는 리소스 자체만 식별하도록 하는 것이 더 좋은 URI 설계다.

 

개선된 API URI 설계

다음은 리소스 식별URI 계층 구조를 활용한 설계 방식이다.

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

이러한 방식은 회원이라는 리소스를 명확하게 식별하고, 그 리소스에 대해 수행할 동작을 HTTP 메서드로 구분하게 된다.

 

리소스와 행위 분리

URI 설계에서 중요한 점은 리소스행위를 분리하는 것이다.

  • URI는 리소스만 식별해야 한다.
  • 행위는 HTTP 메서드를 사용해 구분해야 한다.

예시

  • 리소스: 회원 (명사)
  • 행위: 조회, 등록, 삭제, 변경 (동사)

행위는 URI에 포함시키지 않고, HTTP 메서드로 구분한다.

  • GET: 조회
  • POST: 등록
  • PUT: 수정
  • DELETE: 삭제

HTTP 메서드 - GET, POST

 

HTTP 주요 메서드

HTTP에서 주로 사용되는 메서드는 다음과 같다.

  • GET: 리소스 조회
  • POST: 요청 데이터를 처리하며 주로 리소스를 등록할 때 사용
  • PUT: 리소스를 대체하며, 리소스가 없을 경우 새로 생성
  • PATCH: 리소스의 일부만 수정
  • DELETE: 리소스를 삭제

기타 HTTP 메서드

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

GET 메서드

GET 메서드는 서버에서 리소스를 조회할 때 사용된다. 클라이언트는 요청 URL을 통해 필요한 데이터를 서버에 요청하며, 서버는 해당 리소스를 조회하여 응답한다. 이 과정에서 GET 메서드는 주로 쿼리 파라미터(query)를 통해 데이터를 전달하며, 메시지 바디를 사용하지 않는 것이 일반적이다.

GET 요청 과정

  1. 리소스 조회 요청
    • 클라이언트가 서버에 GET 요청을 보냄 (예: /members/100)
  2. 서버로 도착
    • 서버에서 요청을 수신하고, 해당 리소스를 조회
  3. 응답 데이터 전송
    • 서버는 클라이언트에게 조회된 데이터를 JSON 형태로 응답

 

POST

POST 메서드는 서버로 데이터를 전송하고 처리하는 데 사용된다. 주로 새로운 리소스를 생성하거나, 전달된 데이터를 기반으로 특정 프로세스를 처리할 때 사용된다. 요청 데이터는 메시지 바디를 통해 전달되며, 서버는 이를 처리한 후 적절한 응답을 반환한다.

POST 요청 과정

  1. 리소스 등록 요청
    • 클라이언트가 서버에 POST 요청을 보내며, 새로운 리소스를 등록하는 데이터를 함께 보냄 (예: /members)
  2. 서버에서 리소스 생성
    • 서버는 요청 데이터를 처리하여 새로운 리소스를 생성하고, 해당 리소스의 URI를 반환
  3. 응답 데이터 전송
    • 서버는 클라이언트에게 새로 생성된 리소스의 정보를 포함한 응답을 보냄 (201 Created)

 

POST 메서드의 역할

POST 메서드는 단순히 데이터를 서버로 전송하는 것이 아니라, 서버에서 해당 데이터를 처리하는 역할을 한다. 구체적으로는 다음과 같은 용도로 사용될 수 있다.

  • HTML 양식 데이터를 처리 (예: 회원 가입)
  • 게시판 글쓰기, 댓글 달기 등
  • 서버가 아직 식별하지 않은 새로운 리소스를 생성
  • 기존 자원에 데이터를 추가 (예: 문서에 새로운 내용 추가)

POST 요청이 오면, 각 리소스마다 데이터를 어떻게 처리할지 따로 정해야 하며, 그 처리 방식은 정해진 것이 없다.

 

POST 정리

  1. 새 리소스 생성: 서버가 아직 식별하지 않은 리소스를 생성할 때 사용
  2. 데이터 처리: 데이터를 생성, 변경, 프로세스 처리 등
  3. 기타: 다른 메서드로 처리하기 어려운 경우 POST를 사용할 수 있다 (예: 복잡한 데이터 처리)

HTTP 메서드 - PUT, PATCH, DELETE

PUT

리소스를 대체

리소스가 있으면 대체

리소스가 없으면 생성

쉽게 이야기해서 덮어버림

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

클라이언트가 리소스 위치를 알고 URI 지정

POST 차이점

PUT

리소스가 있는 경우

클라이언트가 서버에 이미 존재하는 리소스를 완전히 대체할 수 있다. 기존 리소스의 모든 정보가 새로운 정보로 덮어 쓰인다.

PUT

리소스가 없는 경우

서버에 해당 리소스가 없으면, 새로운 리소스를 생성한다. PUT 메서드는 클라이언트가 해당 URI에 대한 리소스를 직접 지정하기 때문에 없는 경우에도 자동으로 생성된다.

PUT

주의! - 리소스를 완전히 대체한다.

PUT 메서드는 리소스 전체를 대체하기 때문에, 기존 리소스에 일부 정보가 사라질 수 있다. 예를 들어, 리소스의 일부 필드를 보내지 않으면 해당 필드는 삭제될 수 있다.

PATCH

리소스 부분 변경

PATCH 메서드는 리소스의 일부만 수정한다. 예를 들어, 나이 정보만 변경할 경우 전체 리소스를 대체하지 않고 일부 필드만 수정된다.

DELETE

리소스 제거

DELETE 메서드는 특정 리소스를 제거하는 데 사용된다. 해당 리소스가 더 이상 서버에 존재하지 않게 된다.

 

HTTP 메서드의 속성

HTTP 메서드에는 세 가지 중요한 속성이 있다.

안전성(Safe Methods), 멱등성(Idempotent Methods), 캐시 가능성(Cacheable Methods).

이 속성들은 메서드의 사용 목적과 동작 방식을 이해하는 데 필수적이다.

 

1. 안전(Safe)

안전한 메서드는 서버에 리소스를 변경하지 않는다. 예를 들어, GET과 HEAD 메서드는 리소스를 단순히 조회하는 용도로 사용되며, 서버에 저장된 데이터를 변경하지 않기 때문에 안전하다. 다만, 이 안전성은 해당 리소스에 한정된다. 즉, 로그가 쌓이거나 서버 자원이 소모되는 등의 부수적인 영향은 고려하지 않는다.

  • 안전한 메서드: GET, HEAD, OPTIONS, TRACE

2. 멱등(Idempotent)

멱등성은 여러 번 호출해도 결과가 달라지지 않는 성질을 의미한다. 즉, 한 번 호출했을 때와 여러 번 호출했을 때의 결과가 동일해야 한다.

  • GET: 한 번 조회하든 100번 조회하든 결과가 동일하다.
  • PUT: 리소스를 대체하기 때문에 여러 번 호출해도 최종 상태는 동일하다.
  • DELETE: 리소스를 삭제하는 작업으로, 한 번 삭제한 후 여러 번 요청해도 상태는 동일하다.

그러나 POST는 멱등성이 없다. 예를 들어, 동일한 결제 요청이 두 번 발생하면 중복 결제가 일어날 수 있다.

  • 멱등한 메서드: GET, PUT, DELETE, HEAD, OPTIONS, TRACE

3. 캐시 가능(Cacheable)

캐시 가능성은 클라이언트가 서버로부터 받은 응답을 캐시 하고, 이를 재사용할 수 있는지 여부를 나타낸다. 대부분 GET과 HEAD는 캐시가 가능하지만, POST와 PATCH는 본문 내용을 고려해야 하므로 캐시로 구현하기 어려운 경우가 많다.

  • 캐시 가능한 메서드: GET, HEAD, POST, PATCH (하지만 실제로는 GET과 HEAD가 주로 캐시로 사용됨)

'FrontEnd > HTTP' 카테고리의 다른 글

[HTTP] HTTP 상태코드  (0) 2024.10.08
[HTTP] HTTP 메서드 활용  (1) 2024.10.07
[HTTP] HTTP 기본  (3) 2024.10.06
[HTTP] URI와 웹 브라우저 요청 흐름  (3) 2024.10.06
[HTTP] 인터넷 네트워크  (1) 2024.10.06