Ajeong

1일 1커밋이 목표 ^.^

모든 개발자를 위한 HTTP 웹 기본 지식 (김영한) 강의 수강 후 정리한 자료입니다.

❗HTTP 메시지 내부의 HTTP 메서드에 대해 알아보자❗Permalink

✨ HTTP API 설계Permalink

  • 리소스 식별을 기준으로 삼아 HTTP API를 설계 해야 한다.
    ex) 회원을 조회하고 등록하는 API를 설계하려고 할 때, 어떠한 행동 (조회, 등록)에 초점을 맞추는 것보다는 그 URI의 리소스인 ‘회원’(리소스)에 초점을 맞춰 설계해야 한다.
  • 계층 구조상 상위를 컬렉션으로 본다.
  • 복수 단어 사용을 권장한다.

리소스를 기준으로 HTTP API를 설계하면 조회와 등록 모두 /members/{id}로 끝나게 된다.

그렇다면 조회나 등록처럼 어떠한 행동을 API로 어떻게 나타낼까?

=> HTTP 메서드를 통해 구분이 가능하다!

✨ HTTP 메서드Permalink

종류Permalink

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

그 외에도 HEAD, OPTIONS, CONNECT, TRACE 등이 있다.

GETPermalink

  • 리소스 조회
  • 서버에 전달하고 싶은 데이터는 query를 통해 전달
  • GET에서 메시지 바디를 통해 데이터를 전달할 수 있지만, 권장하지는 않음.

POSTPermalink

  • 요청 데이터 전달
  • 메시지 바디를 통해 클라이언트에서 서버로 요청 데이터 전달
  • 서버는 받은 요청 데이터를 처리
  • 신규 리소스 등록 (ex, 회원 등록), 프로세스 처리(ex, 결제 완료, 배달, 시작, 배달 완료 과정의 상태 처리)에 사용

정리Permalink

  • POST는 등록 뿐만 아니라 요청을 “처리”한다.
  • 받은 HTTP 메시지에 신규 리소스 식별자를 생성하여 경로 반환
    -> 그러나 POSt의 결과로 새로운 리소스가 생성되지 않을 수도 있음
  • 다른 메서드로 처리하기 애매한 경우에도 POST를 사용한다.


ex) 회원 등록

members/로 요청을 보내면 신규 리소스 식별자를 생성(200)하여 경로(members/200/)를 반환한다. 이렇게 되면 200번째 회원이 등록되는 것이다.

PUTPermalink

  • 리소스를 “완전히” 대체 (리소스를 덮어버림)
  • 없으면 생성
  • POST와 가장 큰 차이점은 클라이언트가 리소스의 전체 경로를 이미 알고 있다는 것.
  • 클라이언트가 리소스를 식별
    ex) 요청 시 members/200을 보냄
  • 완전히 대체되므로 필드가 사라질 가능성도 있음.
    -> age, name 필드가 있는데 age만 PUT으로 수정하려고 보내면 name 필드가 사라질 수도 있다.

이럴 때 PATCH를 사용함

PATCHPermalink

  • 리소스 부분 변경
  • PUT처럼 클라이언트가 리소스를 식별함.
  • 바꾸고 싶은 부분만 보내면 알아서 업데이트
  • PATCH가 지원되지 않는 서버인 경우 POST를 사용

DELETEPermalink

  • 리소스 제거
  • 클라이언트가 리소스 식별자를 포함한 URI를 보내면 그 리소스가 지워짐.

✨ HTTP 메시지 속성Permalink

  1. 안전 (Safe Methods)
  2. 멱등 (Idempotent Methods)
  3. 캐시가능 (Cacheable Methods)

안전Permalink

: 호출해도 리소스를 변경하지 않음.

  • GET이 이에 해당됨.
  • 당연히 리소스를 변경하는 PST PUT, DELETE는 안전하지 않음.
  • 나머지는 고려하지 않음.

멱등Permalink

: 한 번 호출하든, 두 번 호출하든, 100번 호출하든 결과가 뜩같음.

  • 최종 결과물을 생각할 것.
  • GET, PUT, DELETE이 이에 해당됨.
  • PUT : 똑같은 파일을 두 번 업로드해도 대체되므로 결과가 똑같음.
  • POST는 두 번 호출 시 같은 결제가 중복해서 발생할 수 있으므로 멱등이 아님.

이러한 멱등은 언제 사용하는가?

  • 자동 복구 메커니즘
  • 서버가 타임아웃 등으로 정상 응답에 실패했을 경우, 클라이언트가 같은 요청을 다시 해도 되는지 판단 여부를 결정함 (서버가 같은 요청을 재실행)

캐시가능Permalink

: 응답 결과 리소스를 웹 브라우저 내부에 저장(캐시)해서 사용할 수 있는가?

cf) 캐시 : 임시 저장 기능이라고 생각하면 쉬움

  • GET, POST, PATCH 캐시 사용 가능
  • 그러나 실제로는 GET, HEAD 정도만 캐시로 사용
  • POST, PATCH는 본문 내용까지 캐시 키로 고려해야 하는데, 구현이 쉽지 않음.

카테고리:

업데이트:

참고