4. HTTP 메서드.md

4. HTTP 메서드

4.1 HTTP API 만들기

API URI 설계

• 리소스를 식별하는것이 관건
  • 미네랄을 캔다
    • 미네랄 → 리소스
    • 캔다 → 행위
  • 회원을 등록한다
    • 회원 → 리소스
    • 등록한다 → 행위
• 리소스를 식별한 후 행위에 해당하는 기능은 어떻게 구분할 것인가?
  • 메소드로 구분
• 정리
  • API 설계 시 리소스와 행위를 분리
  • URI는 리소스만 식별
  • 행위는 메소드로 구현

4.2 HTTP 메소드 종류

1. GET

리소스를 조회하는 메소드

• 쿼리를 통해 서버로 데이터를 전달

• 메시지 바디를 통해서도 데이터를 전달할 수 있지만 권장하지 않음

  

2. POST

데이터 처리를 요청하는 메소드

• 스펙

  • POST 메소드는 대상 리소스가 리소스의 고유한 의미 체계에 따라 요청에 포함된 표현을 처리하도록 요청합니다. → 리소스 URI에 POST 요청이 오면 요청 데이터를 어떻게 처리할 지 리소스마다 따로 정해줘야 함 (정해진 것이 없음)

• 가장 강력한 메소드 → 뭐든 다 할 수 있음

• 메시지 바디를 통해 서버로 데이터 전달

• 서버는 전달받은 데이터를 처리

  • ex) 신규 리소스 등록, 프로세스 처리 등

• 처리 과정 (새 리소스 생성)

  1. 클라이언트가 서버로 메세지 전달
  2. 신규 리소스 식별자 생성
  3. 서버가 응답

• POST 메소드로 처리하는 일

  1. 새 리소스 생성 (등록)
  2. 요청 데이터 처리
     • 단순히 데이터를 생성하거나 변경하는 것을 넘어서 프로세스를 처리해야 하는 경우
     • ex) 주문 결제 완료 → 배달 시작 → 배달 완료
       • 과정이 바뀔 때 POST로 프로세스 변경을 처리
       • POST /orders/{ordeId}/start-delivery → 컨트롤 URI
         • 컨트롤 URI → 리소스만으로 URI를 설계할 수 없을 때 동사 형태의 URI 만듦
     • 리소스의 생성이 없을 수도 있음
  3. 다른 메서드로 처리하기 애매한 일 처리

3. PUT

리소스를 완전히 대체하는 메소드

• 폴더에 파일 넣기와 비슷

  • 같은 파일이 없으면 → 파일 생성
  • 같은 파일이 있으면 → 파일 덮어 씌움

• POST와 차이점

  • POST는 리소스의 위치를 몰라도 됨
  • PUT은 클라이언트가 리소스의 위치를 알고 URI를 지정해야 함

• 수정이 아니라 대체!

4. PATCH

리소스를 수정할 때 사용

• 리소스의 위치를 알아야 함 (URI 지정)

5. DELETE

리소스를 제거

• 리소스의 위치를 알아야 함 (URI 지정)

URI 지정 → PUT, PATCH, DELETE

• 메소드를 적용할 리소스의 URI를 모르면 사용할 수 없다!

4.3 HTTP 메소드의 속성

1. 안전 (Safe Methods)

메소드를 호출해도 리소스를 변경하지 않음

• get만 안전

2. 멱등 (Idempotent Methods)

메소드를 한번 호출하든 100번 호출하든 결과가 똑같음

• get, put, delete - 멱등 o
  • get → 한번 조회하든 100번 조회하든 똑같음
  • put → 1번 덮어씌우든 100번 덮어씌우든 똑같음
• post, patch - 멱등 x
  • post → 2번 호출하면 2번 결제됨
• 활용 - 자동 복구 메커니즘
• delete 요청 시 응답 없음 → 다시 delete 요청

3. 캐시 가능 (Cacheable Methods)

웹 브라우저 내부에 응답받은 리소스를 저장할 수 있는가