HTTP 메서드

만약 아래와 같은 회원 정보 관리 API를 만들어야 한다면 URI를 어떻게 설계해야할까?

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

위 사진과 같이 설계하는 것이 과연 좋은 설계일까? 라고 묻는다면 아니다.
가장 중요한 것은 리소스 식별 이다.

리소스의 의미는 무엇일까?
회원을 등록하고 수정하고 조회하는 것이 리소스가 아니다.
'회원'이라는 단어(개념) 자체가 리소스이다.
리소스는 동사, 행위, 행동 등에 대한 것을 배제하고 남은 개념들을 리소스라고 판단하면 되겠다.

위 내용과 같이 회원이라는 것을 하나의 리소스로 정의하여 /members 로 정의하였다.

그렇다면 '행동'에 대한 부분은 어떻게 정의해야할까? 그러한 행동에 대해서는 이제 HTTP 메서드의 개념이 등장한다.

HTTP 메서드 - GET

GET 메서드는 요청 API를 통해 리소스를 조회하는 역할을 한다. 예를 들면 유저 조회, 특정 아이템 조회 같은 단순히 '읽어오는' 메서드이다.

이전에 배웠던 HTTP 메세지의 형태를 띈다. 응답 데이터의 바디 부분은 해당 요청사항의 데이터를 가져온다.

HTTP 메서드 - POST

POST는 요청 데이터를 처리하는 것 뿐만 아니라 데이터를 읽어올 수도 있으며 수정할 수 있다. 그렇다면 모든 것을 POST로 처리할 수 있지 않을까 라고 생각할 수 있지만, 뒤에 살펴볼 '멱등'이라는 부분에 의해 온전히 모든 것을 POST로 처리할 수만은 없다. 또한 GET은 단순히 데이터를 요청하여 읽어오는 것이라 캐싱전략 등을 사용할 수 있는 반면 POST는 그렇지 않다.

GET과는 다르게 요청 데이터에 메세지를 담아 요청을 하면 '등록'이 되고 결과를 반환받을 수 있다.
다만 URI에 POST 요청이 오면 요청 데이터를 어떻게 처리할 것인지는 리소스마다 따로 정해야한다.

HTTP 메서드 - PUT

쉽게 생각해서 파일과 폴더라고 생각하면 편하다. 폴더에 파일이 없다면 등록하고 있다면 덮어씌우는(대체) 방식이다.

리소스가 있는 경우엔 위의 내용들처럼 리소스가 덮어씌워진다.

리소스가 없는 경우엔 신규 리소스로 생성된다.

PUT의 주의할 점은 리소스를 완전히 대체한다는 점이다. 위의 상황처럼 리소스가 덮어져 필드가 삭제될 수 있다.

HTTP 메서드 - PATCH

PATCH는 리소스의 부분 변경을 진행한다.

HTTP 메서드 - DELETE

DELETE 메서드는 해당 리소스를 제거한다.

HTTP 메서드의 속성

• 안전 (Safe Methods)
• 멱등 (Idempotent Methods)
• 캐시 가능(Cacheable Methods)

안전

• 호출해도 리소스가 변경되지 않는다.
• GET,HEAD는 리소스를 변경하는 사항이 없기 때문에 안전하다고 볼 수 있다.

멱등

• 한 번 호출하든 두 번 호출하든 백 번호출하든 결과가 똑같다.
• GET : 조회 결과는 항상 같다.
• PUT : 같은 요청으로 대체해도 항상 같은 결과가 나오므로 해당된다.
• DELETE : 삭제 요청을 여러 번 진행해도 같은 결과가 나오므로 해당된다.
• POST : 멱등이 아니다. 두 번 호출하면 중복 결제 등의 가능성이 있으므로 해당되지 않는다.

캐시 가능

• 응답 결과를 캐싱해서 사용해도 되는지에 대한 부분
• GET,HEAD,POST,PATCH 가 캐시 가능하다.
• 실질적으론 GET,HEAD 정도만 캐시로 사용한다.

해당 내용은 김영한님의 HTTP 웹 기초 강의(인프런)의 자료와 내용을 사용하였습니다.