Http는 URI, Body 뿐만 아니라 Method에 대한 정보도 포함되어 있다.
해당 메소드는 몇가지 특징과 약속이 있으며 이를 조합하여 REST API를 설계하게 된다.

해당 메소드에 대해서 몇가지 공통적인 특징이 존재한다.
말그대로 무엇인가를 가져오는 데 사용하는 Method이다.
대표적으로 4가지 특징을 가지게 된다.
물론 몇몇 http 버전은 body에 데이터를 담는 것을 허용한다. 하지만 말 그대로 일부 버전이기 때문에 추천하지 않는 방식이다.
ex) GET /members?q=hello = 맴버목록 조회
데이터를 새로 저장하거나, 여러 논리적 상황에서 사용되는 만능 Method이다.
만능 Method 중 하나이다.
요청과 결과를 body를 통해서 보내고 받을 수 있으며, 그 의미가 등록이기 때문에
전체적으로 데이터를 바꾸어버리는 PUT이나 일부 내용만 수정하는 PATCH에 를 사용하기 어렵거나 애매할 때 자주 사용하는 기능이다.
ex) POST /members = 멤버 가입
데이터를 전부 갈아 치울 때 사용한다. 데이터가 없다면 해당 데이터를 저장한다.
어떻게 보면 POST와 비슷한 기능을 하는 Method 이다.
POST와 가장 큰 차이점이라면 리소스 주소를 아느냐 모르느냐이다.
그렇기에 파일의 저장, 게시글 수정 등에 많이 사용한다 (파일명 = id)
또한 PATCH와는 다르게 리소스의 모든 데이터가 저장되어 있다.
말그대로 "대체"이기 때문에 요청에 정보가 누락되면 null 데이터가 들어가는 등 예측 불가능한 상황이 나온다.
ex) PUT /posts/{id} = 게시글 수정
데이터의 일부를 수정할 때 사용한다.
PUT과 어떻게 보면 비슷하지만 차이가 존재하는 기능이다.
주로 특정 리소스의 일부 수정에 많이 사용하며, 완전히 대체되지 않는다.
이러한 특징 때문에 특정 데이터가 변환되서는 안되는 유저 데이터 수정 같은 상황에 사용한다.
ex) PATCH /members/{id} = 멤버 수정
데이터의 삭제에 사용된다.
데이터 삭제에 사용한다.
ex) DELETE /members/{id} = 멤버 탈퇴

사실 해당 Method의 규칙을 지키지 않아도 된다.
DELETE를 GET으로 PATCH를 삭제로 사용하는 등 엉뚱한 방식으로 사용해도 무관하다.
하지만 그렇게 사용한다는 것은 위의 예시와 동일하다.
해당 방식은 API 설계에 대한 기본약속이다.
몇가지 상황으로 인해 제약이 생겨 해당 방식을 다르게 계량하는 방식도 존재한다.
예로들어 HTML Form 으로만 API를 사용할 경우 GET과 POST만 사용이 가능하다.
이런 경우 조회의 기능은 대부분 GET, 수정 등록 삭제의 경우는 POST를 사용하고
URL에 일부 동사를 첨삭하여 이를 대체한다.
POST /members/new - 맴버 등록
GET /members/new - 맴버 등록 페이지
GET /members/{id} - 특정 맴버 조회
POST /members/{id}/delete - 맴버 탈퇴