[HTTP] HTTP 메서드

---

API URI 설계 방법

우선 프로젝트를 설계할 때 URI마다 역할을 나눠서 보여주기 위해

알아보기 쉬운 URI를 설계해야 합니다.

 

HTTP의 기능을 그대로 지키며 최대한 HTTP의 능력을 뽑아내기 위해서는

URI의 계층 구조를 활용하여 설계해서 리소스를 식별할 수 있어야 합니다.

리소스와 해당 리소스를 대상으로 하는 행위를 분리합니다.

여기서 리소스는 회원이며, 행위는 조회, 등록, 삭제, 변경을 의미합니다.

이제 이 행위를 HTTP 메서드로 구분합니다.

 

주요 메서드의 기능을 구분하면 이러합니다.

GET : 리소스 조회

POST : 요청 데이터 처리, 주로 등록에 많이 사용

PUT : 리소스를 대체, 해당 리소스가 없으면 새로 생성

PATCH : 리소스 부분 변경, 특정 필드 몇개만 바꿀 때 사용

DELETE : 리소스 삭제

---

GET

리소스를 조회해달라는 행위입니다.

서버에 전달하고 싶은 데이터는 URI, 주로 쿼리 스트링을 통해서 전달합니다.

메세지 바디를 사용해서 전달할 수도 있지만, 지원하지 않은 곳이 많아서 주로 URI에 붙여서 보냅니다.

 

"100번째 맴버 정보를 조회해줘"

---

POST

요청 데이터를 처리해달라는 행위입니다.

메세지 바디를 통해서 서버로 요청 데이터를 전달하고 서버는 이 데이터를 처리합니다.

"아이디랑 비번, 이메일 같은 정보 줄태니까 이걸 등록하거나 해줘"

정말 여러가지에 쓰이는데 대표적으로 3가지만 간추려보면 이러합니다.

새 리소스를 생성

서버가 아직 식별하지 않은 새로운 리소스를 생성할 수 있습니다.

 

요청 데이터 처리

프로세스 단위로 처리해야 하는 경우입니다.

배달의 민족 앱에서 결제가 완료되었으면 가게 사장님이 배달 시작이라는 버튼을 누르게 될 것입니다.

이는 단순히 "배달 시작"이라는 문자만 바꾸면 되는 것이 아니라 이 버튼을 누름으로써

뒷단의 배달 시작과 관련된 새로운 프로세스들의 상태가 변경될 것입니다.

 

컨트롤 URI

URI를 리소스만으로 설계하기엔 현실적으로 힘든 부분이 있습니다.

이럴 때 어쩔수 없이 start-delivery 같은 동사를 사용해야 하는데 이를 컨트롤 URI라 합니다.

이 경우에 주로 POST로 하며 이는 새로운 리소스가 생기지 않습니다.

 

애매한 경우

JSON으로 메세지 바디에 넣어 데이터를 넘겨야 되는데 GET 메서드를 사용하기 어려운 경우

POST를 사용합니다.

 

이처럼 POST는 사실 모든 행위를 할 수 있을 정도로 사용성이 방대합니다.

하지만 GET보다 캐싱 처리가 어렵다는 단점이 있어 이를 생각하며 설계해야 합니다.

---

PUT

리소스를 대체하는 행위입니다.

파일 복사와 붙여넣기와 비슷한 느낌입니다.

대체하거나 새로 덮어버립니다.

 

POST와 달리 PUT은 리소스 위치를 지정합니다.

다음 JSON 파일을 보내려고 할 때 PUT을 사용한다면 그 리소스 자체를 덮어버립니다.

---

PATCH

리소스를 부분 변경하는 행위입니다.

PUT에서 완전히 대체되지 않고 부분적으로만 대체하고 싶어서 나온 메서드입니다.

새로나온 메서드라 아직 서버에서 PATCH를 지원하지 않는 경우도 있습니다.

그럴 경우에는 POST로 사용하면 됩니다.

 

---

DELETE

리소스를 제거하는 행위입니다.

경로에 있는 리소스를 제거합니다.

---

HTTP 메서드 속성

안전 safe

메서드를 통해 리소스를 호출해도 리소스 자체를 변경하지 않으면 안전하다고 표현합니다.

리소스 자체만을 고려하며, 로그 등 외부 요인까지 고려하지 않습니다.

GET은 안전하며 나머지 메서드들은 서버의 리소스들이 변경되므로 안전하지 않습니다.

 

멱등 idempotent

f(f(x)) = f(x)

즉, 한 번, 두 번, 100번 호출해도 결과가 똑같다면 멱등하다고 합니다.

멱등도 마찬가지로 외부 요인으로 중간에 리소스가 변경되는 것 까진 고려하지 않습니다.

 

GET은 두 번 조회하든 같은 결과가 조회됩니다.

PUT은 결과를 대체하므로 결과는 항상 대체된 같은 결과가 나옵니다.

DELETE는 결과를 삭제하므로 계속 요청해도 삭제 결과는 동일합니다.

POST는 한 번 호출하는 것과 두 번 호출하는 것의 결과가 다르니 멱등하지 않다고 합니다.

예를 들어 결제에서 POST로 두 번 호출할 경우 같은 결제가 중복해서 발생하게 되므로 결과가 다릅니다.

 

캐시가능 Cacheable

임시로 파일을 저장해두어 나중에 같은 URI로 접속할 때 더 빠르게 로딩하기 위함입니다.

캐시가능이라함은, 요청에 대한 응답 결과 리소스를 캐시해서 사용 가능한가를 의미합니다.

GET, HEAD, POST, PATCH가 캐시 가능하나 실제로는 GET, HEAD만 한다고 합니다.

POST와 PATCH는 바디 본문 내용까지 캐시 키로 고려해야하는데 이를 구현하기가 쉽지 않다고 합니다.

그래서 구현하기 쉬운 GET, HEAD를 캐시가능하다고 합니다.

---

참조

모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 | 강의