4. HTTP 메서드

이 포스팅은 인프런 김영한 강사님의 <모든 개발자를 위한 HTTP 웹 기본 지식>을 수강하고, 공부하여 글로 정리한 것입니다. 그대로 갖다 붙여넣는 내용이 아니라 기억나는대로 작성한 후 다시 추가적으로 정리하는 방식을 취하고 있기 때문에 틀린 부분이 있을 수 있습니다. 잘못된 점은 짚어주시면 감사하겠습니다.

1. HTTP API 만들기

API URI 고민

회원을 등록하고, 수정하고, 조회하는 게 리소스가 아니다.
회원이라는 개념 자체가 리소스이기 때문에, 회원이라는 리소스만 식별하여 URI에 매핑하면 된다.

/* 회원 목록 조회 */ /members
/* 회원 조회 */ /members/{id}
/* 회원 등록 */ /members/{id}
/* 회원 수정 */ /members/{id}
/* 회원 삭제 */ /members/{id}  // 조회, 등록, 수정, 삭제 구분 문제 발생

URI는 리소스만 식별하므로, 리소스와 해당 리소스를 대상으로 하는 행위를 분리한다.

• 리소스 : 회원
• 행위(메서드) : 조회, 등록, 수정, 삭제
  
  

2. HTTP 메서드

1. GET

리소스 조회.
메시지 바디 사용 가능하지만 권장되지 않고, 서버에 데이터를 전달할 때 주로 쿼리 스트링을 통해서 전달한다.

2. POST

요청 데이터 처리.
메시지 바디를 통해서 서버로 요청 데이터를 전달하고, 서버는 요청 데이터를 처리한다.
주로 신규 데이터 등록이나 프로세스 처리에 사용된다.

정리

1. 새 리소스 생성
2. 요청 데이터 처리

• 단순 데이터 생성/변경을 넘어 프로세스를 처리해야 하는 경우
• 예) 주문 -> 결제완료 -> 배달시작 -> 배달완료 와 같이 값 변경을 넘어 프로세스 상태가 변경되는 경우
• POST 결과로 새로운 리소스가 생성되지 않을 수도 있음

3. 다른 메서드로 처리하기 애매한 경우

3. PUT

리소스 대체. 해당 리소스 없으면 새로 생성.
기존의 리소스가 있으면 전달한 리소스가 기존의 리소스를 "완전히" 대체하고, 없으면 새롭게 생성한다. 즉, 덮어쓰기.

POST와의 차이점?

PUT은 클라이언트가 리소스 위치를 알고 URI를 지정하는 것.

완전히 대체한다? 기존의 리소스에 username과 age 필드가 있다고 할 때, PUT으로 리소스에 age만 작성하여 서버에 전달하면 age의 값만 변경되는 것이 아니라 username은 사라지고, age만 남는다. 즉, 기존의 리소스는 사라지고 새로운 리소스가 그 자리를 차지하는 것이다.

4. PATCH

리소스 부분 변경.
PUT은 기존의 리소스를 완전히 대체하기 때문에 부분 변경을 하고 싶다면 PATCH를 사용하면 된다.

5. DELETE

리소스 삭제.

6. 기타

• HEAD : GET과 비슷하지만, 상태줄과 헤더만 반환.
• OPTIONS : 대상 리소스에 대한 통신 가능 옵션(메서드)을 설명(주로 CORS에서 사용)
• CONNECT
• TRACE
  
  

3. HTTP 메서드의 속성

1. 안전(Safe)

호출해도 리소스를 변경하지 않는다. 다만, 지속적인 호출로 로그가 쌓여 장애가 발생하는 등의 부분까지는 고려하지 않는다.

2. 멱등(Idempotent)

멱등 (冪等) : 연산을 여러 번 적용하더라도 결괏값이 달라지지 않는 일.

몇 번 호출하든 호출 결과는 동일하다. 그러나, 외부 요인으로 중간에 리소스가 변경되는 것까지는 고려하지 않는다.(ex> GET 요청 중간에 다른 사용자가 PUT을 통해 데이터를 수정하는 경우)
GET, PUT, DELETE는 멱등이지만, POST는 멱등이 아니다.
자동 복구 메커니즘과 같은 곳에 활용된다.

3. 캐시 가능(Cacheable)

캐시 : 리소스를 요청하는 경우, 그 후에 계속 새로 요청하여 발생하는 불편을 방지하고자 웹브라우저 내부에 저장해두는 것

응답 결과 리소스를 캐시해서 사용할 수 있는가.
GET, HEAD, POST, PATCH가 스펙상 캐시가능하지만, 실제로는 GET, HEAD 정도만 캐시로 사용한다.
POST, PATCH는 본문 내용까지 캐시 키로 고려해야 하는데, 구현이 쉽지 않기 때문.