HTTP 메소드

HTTP API 만들기 (가상)

00. 요구 사항

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

01. URI 설계

  • 리소스 식별이 가장 중요 (URI 설계의 기준)
  • 위의 요구 사항 중 회원이 리소스
  • URI는 계층 구조 => 상위를 컬렉션으로 보고 복수단어 사용 권장 (member -> members)
  • 리소스와 행위를 분리해라
    • URI는 리소스만 식별
    • 리소스는 명사, 행위는 동사
    • 행위의 구분은 HTTP 메소드가 대신 해준다!

HTTP 메소드 종류

  • 주요 메소드
    • GET : 리소스 조회
    • POST : 요청 데이터 처리 (주로 등록)
    • PUT : 리소스를 대체, 해당 리소스가 없으면 생성
    • PATCH : 리소스 부분 변경
    • DELETE : 리소스 삭제
  • 기타 메소드
    • HEAD : GET과 동일하지만 메세지(바디) 부분을 제외하고, 상태 줄과 헤더만 반환
    • OPTIONS : 대상 리소스에 대한 통신 가능 옵션을 설명 (CORS에서 사용)
    • CONNECT : 대상 자원으로 식별되는 서버에 대한 터널을 설정
    • TRACE : 대상 리소스에 대한 경로를 따라 메세지 루프백 테스트 수행

GET

  • 리소스 조회
  • query를 통해서 서버에 전달
  • 메세지 바디를 사용해서 데이터 전달 가능 => 권장하지 X

POST

  • 대상 리소스가 리소스 고유한 의미 체계에 따라 요청에 포함된 표현을 처리하도록 요청하는 메소드
  • 요청 데이터 처리, 신규 리소스 등록, 프로세스 처리에 주로 사용
  • 메세지 바디를 통해 클라이언트에서 서버로 요청 데이터 전달
  • 서버에서 받은 요청 데이터 처리 (메세지 바디를 통해 들어온 데이터 처리에 관한 모든 기능 수행)
  • 리소스 단위 만으로 URI를 꾸리지 못하는 경우가 있음 => 어쩔 수없이 컨트롤 URI 사용
  • 다른 메소드로 처리하기 애매하면 그냥 POST 사용

PUT

  • 리소스를 대체
    • 덮어쓰기와 유사
    • 있으면 대채
    • 없으면 생성
    • 완전 대체 => 단순 수정이 아니라 기존 데이터를 새 데이터로 갈아치움
  • 클라이언트가 리소스를 식별
    • 클라이언트가 구체적인 리소스의 위치를 다 알고 URI를 지정 (POST와의 차이점)

PATCH

  • 리소스 부분 변경
  • 데이터 필드를 부분적으로 변경할 수 있음 (PUT은 이게 안돼)
  • 간혹 지원이 안 되는 경우가 있음 => POST로 대체

DELETE

  • 리소스 제거

HTTP 메소드의 속성

  • 안전
    • 호출해도 리소스를 변경하지 않음
  • 멱등 (Idempotent)
    • 한 번 호출하든 두 번 호출하든 100번 호출하든 결과가 똑같음
    • GET PUT DELETE
    • POST는 멱등이 아님!!!
    • 자동 복구 매커니즘
  • 캐시 가능
    • 응답 결과 리소스를 캐시해서 사용할 수 있나?
    • GET HEAD POST PATCH
    • 실제로는 GET HEAD 정도만 캐시로 사용 (나머지 두개는 구현이 어려움)



인프런 - 김영한님의 모든 개발자를 위한 HTTP 웹 기본 지식을 정리한 내용입니다.


김영한님 인프런 강의

댓글남기기

참고