본문 바로가기

Dev/TIL

[HTTP] HTTP 메서드 - GET, POST, PUT, PATCH, DELETE

 

[HTTP 메서드란?]

클라이언트가 서버에게 무엇인가를 요청할 때 기대되는 행위를 말한다.

 

 

GET : 리소스 조회

- 서버에 전달할 데이터는 쿼리 스트링, 쿼리 파라미터 형태로 전달한다.

- url에 적혀있는 path에 따라 리소스를 요청한다.

- 주로 캐싱이 필요한 작업일 때 사용한다.

 

 

POST : 주로 등록, 요청하는 데이터에 대한 처리

- 데이터를 <form>과 같은 곳에 담아서 클라이언트가 서버로 전달한다.

- 메시지 바디를 이용해서 요청할 데이터를 서버로 전달한다.

- POST 메서드는 서버에서 위와 같이 전달된 데이터를 처리하는 모든 기능을 수행한다.

- 사전에 정해진 path로 전달된 데이터는 서버에서 처리하기로 약속이 되어있어야 한다.

- 주로 신규 등록(데이터 생성), 프로세스 변경(프로세스의 상태가 변경되는 경우)에 이용

- 예를 들어 신규 회원 등록을 한다면, 클라이언트는 요청할 데이터를 전달하고 -> 서버에서는 전달받은 데이터를 처리하여 데이터베이스에 등록하고 생성된 신규 리소스에 대한 식별자를 생성해서 response 로 내려준다.

- 다른 메소드로 대체하기 애매할 경우에 POST를 사용한다.(ex. JSON으로 데이터를 넘겨야 하는데 GET 메소드를 사용하기 어려움)

 

- 클라이언트는 등록될 리소스의 URI를 모른다. 서버가 새로 등록될 URI를 자동으로 생성해준다.

 

- 컬렉션(Collection)

-> 서버가 관리하는 리소스 디렉터리

-> 서버가 리소스의 URI를 생성하고 관리한다. 

 

 

PUT : 리소스를 대체하거나 해당 리소스가 없다면 생성

- ex. 폴더에 파일 넣기(폴더에 파일이 없었다면 새로 생기고, 있었다면 위에 덮어 씌울 수 있다.)

- 리소스가 이미 존재한다면 대체한다. (덮어 씌운다.)

- 리소스가 없다면 새로 생성한다.

- POST와의 차이점 : POST와 달리 PUT은 사용자가 리소스를 식별한다. 정확히 리소스가 어떻게, 어디에, 몇 번째로 처리 될지 알고 URI에 지정한다.

- 즉, 클라이언트는 리소스의 URI를 알고 있어야 하고, 직접 지정한다.

 

- 스토어(Store)

-> 클라이언트가 관리하는 리소스 디렉터리

-> 클라이언트가 리소스의 URI를 생성하고 관리한다. 

 

- 주의점 : 리소스를 완전히 대체하기 때문에 일부분만 갱신이 어렵다. (기존 리소스를 삭제하고 완전히 대체한다.) 그래서 수정의 개념이 아니라 대체의 개념으로 봐야한다. -> 수정을 원한다면 PATCH을 쓰자.

 

 

 

PATCH : 리소스 부분 변경

- ex. 회원이라는 리소스의 나이, 학력 등 일부 필드만 변경하는 것

- 리소스의 부분만 변경, 수정이 가능하다.

- 간혹 PATCH가 지원이 안되는 서버가 존재할 수 있다.

 

 

 

DELETE : 리소스 삭제

- 리소스를 제거한다.