[HTTP] HTTP Method (API, GET, POST, PUT, PATCH, DELETE)

회원 정보 관리 API 설계 요구사항으로 아래와 같이 주어졌다고 하자

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

URI를 설계하는 단계에서 

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

위와 같이 직관적으로 URI를 작성하는 것은 바람직하지 않은 방법이다.

 

가장 중요한 것은 리소스 식별 !

 

• 그렇다면 리소스란 무엇일까?
  • 회원을 등록하고 수정하고 조회하는 것이 리소스가 아님
  • 회원이라는 개념 자체가 바로 리소스

• 리소스는 어떻게 식별하는게 좋을까?
  • 회원이라는 리소스만 식별 -> 회원 리소스를 URI에 매핑
• 회원 목록 조회 /members
  • 회원 조회 /members/{id}
  • 회원 등록 /members/{id}
  • 회원 수정 /members/{id}
  • 회원 삭제 /members/{id}

---

- HTTP GET

• 리소스 조회
• 서버에 전달하고 싶은 데이터는 query(쿼리 파라미터, 쿼리 스트링)를 통해서 전달
• 메시지 바디를 사용해서 데이터를 전달할 수 있지만, 지원하지 않는 곳이 많아서 권장하지 않음

- HTTP POST

• 요청 데이터 처리
• 메시지 바디를 통해 서버로 요청 데이터 전달
• 서버는 요청 데이터를 처리
• 메시지 바디를 통해 들어온 데이터를 처리하는 모든 기능을 수행
• 전달된 데이터로 신규 리소스 등록, 프로세스 처리에 사용

※ 요청 데이터를 어떻게 처리한다는 뜻일까?

* POST는 다음과 같은 기능에 사용됩니다.

• HTML 양식에 입력 된 필드와 같은 데이터 블록을 데이터 처리 프로세스에 제공.
  • 예) HTML FORM에 입력한 정보로 회원 가입, 주문 등에서 사용
• 게시판, 뉴스 그룹, 메일링 리스트, 블로그 또는 유사한 기사 그룹에 메시지 게시
  • 예) 게시판 글쓰기, 댓글 달기
• 서버가 아직 식별하지 않은 새 리소스 생성
  • 예) 신규 주문 생성
• 기존 자원에 데이터 추가
  • 한 문서 끝에 내용 추가하기
• 정리하면, 이 리소스 URI에 POST 요청이 오면 요청 데이터를 어떻게 처리할지 리소스마다 따로 정해야 함

 

 

POST 정리

• 새 리소스 등록
  • 서버가 아직 식별하지 않은 새 리소스 생성
• 요청 데이터 처리
  • 단순히 데이터를 생성하거나, 변경하는 것을 넘어서 프로세스를 처리해야 하는 경우
  • 주문에서 결제완료 -> 배달시작 -> 배달완료 처럼 단순히 값 변경을 넘어 프로세스의 상태가 변화되는 경우
  • POST의 결과로 새로운 리소스가 생성되지 않을 수도 있음
• 다른 메서드로 처리하기 애매한 경우
  • JSON으로 조회 데이터를 넘겨야 하는데, GET 메소드를 사용하기 힘든 경우
  • 애매하면 POST

---

- HTTP PUT

• 리소스를 대체
  
  • 리소스가 있으면 대체
  • 리소스가 없으면 생성
  • 쉽게 이야기해서 덮어버림
• 중요!! 클라이언트가 리소스를 식별
  • 클라이언트가 리소스 위치를 알고 URI 지정
  • POST와 차이점
• PUT은 덮어버리는 특성이 있으므로 필요한 파라미터를 정확하게 전달해야된다

 

- HTTP PATCH

• 리소스 부분 변경
• PUT 에서는 모든 데이터를 덮어버렸지만 PATCH는 필요한 리소스만 변경

 

- HTTP DELETE

• 리소스 삭제