[네트워크] HTTP 메소드 (GET, POST, PUT, PATCH, DELETE)

 

웹개발자로 취준을 하다보면 자격 요건에 RESTfuls API 사용 경험, 개발 가능이 많이 보인다. REST에 대한 정의가 궁금해 따로 포스팅해둔 적이 있다. 이때는 많은 부분이 이해가 되지 않았었는데 하나씩 개념이 쌓여갈수록 점점 머릿속으로 들어오는 기분이다. 지금까지 REST에 GET, POST, PUT, DELETE를 대부분 사용하는 줄 알았는데 아니었다.!!!!! PUT보단 PATCH라니! 지금부터 HTTP Method에 대해 알아보려고 한다. 

 

 

---

 

📑 REST와 HTTP에 대한 내용은 참고! 

 

 

https://wonisdaily.tistory.com/82

[server] REST, REST API, RESTful 정의, 특징, 사용법

https://wonisdaily.tistory.com/109

[네트워크] HTTP란? (특징, 구조, 상태, 메시지)

 

 

 

📑 HTTP 메서드의 종류

 

주요 메서드엔 뭐가 있을까?

 

📌 GET : 리소스 조회
📌  POST : 요청 데이터 처리, 주로 등록에 사용
📌  PUT : 리소스를 대체, 해당 리소스가 없으면 생성
📌  PATCH : 리소스 부분 변경
📌  DELETE : 리소스 삭제
📌  HEAD :  GET과 동일하지만 메시지 부분을 제외하고, 상태 줄과 헤더만 반환
📌  OPTIONS : 대상 리소스에 대한 통신 가능 옵션(메서드)을 설명 (주로 CORS에서 사용)

 

 

이렇게 요약된 내용만 봐서 이전에 알던 개념이랑 크게 다를 건 없어보이는데,,? 싶다면 바로 개념 정리를 해볼까한다.

 

 

📑 GET

 

✔ GET은 주로 리소스를 조회하는데 사용되는 메서드이다. 즉) 데이터를 읽거나 검색할 때 사용된다. 

✔ 서버에 전달하고 싶은 데이터는 query(쿼리  파라미터, 쿼리 스트링)을 통해서 전달한다. 

✔ 메시지 바디를 사용해 데이터를 전달할 수 있지만, 지원하지 않는 곳이 많아서 권장하지 않는다. 

✔ 만약 GET 요청이 성공적으로 이뤄진다면 XML이나 JSON과 함께 200 (OK) HTTP 응답 코드를 리턴한다. 만약 에러가 발생한다면 주로 404(Not found)나 400(Bad request) 에러가 발생한다. 

 

 

 

데이터를 조회하는 것이 목적이기에 요청 시 Body 값과 Content-Type이 비워져있다. 조회할 데이터에 대한 정보는 URL을 통해 파라미터로 받는다. 

 

 

 

 

📑 POST

 

✔ POST 메서드는 주로 새로운 리소스를 생성할 때 사용된다. 

✔ 메시지 바디를 통해 서버로 요청 데이터를 전달하며, 서버는 그저 처리해주는 작업을 한다. 즉) 메시지 바디를 통해 들어온 데이터를 처리하는 기능을 수행하는 것.

✔ 주로 전달된 데이터로 신규 리소스를 등록하거나, 프로세스 처리에 사용한다.

✔ 성공적으로 요청을 완료한다면 201 HTTP 응답을 반환한다. 

 

 

POST는 데이터를 생성하는 것이기 때문에 요청시에 Body값과 Content-Type 값을 작성해야 한다. JSON을 사용한 예시이다. URL을 통해 데이터를 받지 않고, Body 값을 통해 받는다. 데이터 조회에 성공한다면 Body 요청한 데이터를 저장하여 성공 응답을 보낸다. 

 

 

 

 

🔨 POST는 요청 데이터를 어떻게 처리하는 걸까? 사용 예시는?

 

POST 메서드는 대상 리소스가 리소스의 고유 한 의미 체계에 따라 요청에 포함 된 표현을 처리하도록 요청한다. 게시판을 구축할 때 그저 POST는 그래! 게시글 삽입, 댓글 삽입에 쓰면 되겠구나 생각했었는데 POST의 사용은 무궁무진하다. 

 

📌 HTML 양식에 입력된 필드와 같은 데이터 블록을 데이터 처리 프로세스에 제공한다.
ex) HTML FORM에 입력한 회원가입, 주문 등
📌 게시판, 뉴스 그룹,블로그 등 메시지 게시
📌 서버가 아직 식별하지 않은 새 리소스 생성 ex) 신규 주문 생성
📌 기존 자원에 데이터 추가 ex) 한 문서 끝에 내용 추가하기

 

POST로 요청 데이터를 처리하는 것은 단순히 데이터를 생성하거나 변경하는 것을 넘어, 프로세스를 처리해야하는 경우도 있다. 따라서 리소스 URI에 POST 요청이 오면 데이터를 어떻게 처리할 것인지 리소스마다 따로 정해야한다. 

 

HTTP URI를 설계할 때 동사에 중심을 두지 말고 명사, 즉 자원에 집중해야 하는데 이는 한계가 있음으로 POST /orders/{orderId}/start-delivery 와 같이 컨트롤URI를 사용할 수도 있다. 

 

 

 

📑 PUT

 

✔ PUT은 리소스를 대체하는 메서드이다. 즉) 리소스를 생성, 업데이트하기 위해 서버로 데이터를 보내는데 사용된다.

✔ PUT에서 중요하게 알아둬야할 점은 리소스가 있으면 완전히 대체, 리소스가 없으면 생성한다. 

 

 

데이터를 수정하는 것이기 때문에 요청시 Body 값과 Content-Type을 작성해서 요청한다. 또한 어떠한 데이터를 수정할지 파라미터도 받는다. 조회 시 해당 데이터가 있을 경우 값을 완전히 대체하기 때문에 빠진 요소가 있어도 대체된다. 따라서 PUT보단 PATCH를 사용하자! 

 

 

 

 

📌 PUT vs POST

 

✔ PUT도 리소스가 없으면 생성한다는데 그럼 POST랑 뭐가달라?  PUT은 클라이언트가 리소스를 식별해서 쿼리로 보낸다. 즉) 리소스 위치를 알고 URI를 지정한다. 이부분이 POST와 차이점이다. 

 

이에관해 더 자세히 얘기해보자면 POST는 POST /members 이런식으로 쿼리를 보내지 않는다. 따라서 서버가 새로 등록된 리소스 URI를 생성해준다. 이렇게 서버가 관리하는 리소스 디렉토리를 컬렉션(Collection)이라고 한다. 

그렇다면 PUT은 클라이언트가 리소스 URI를 알고 있어야한다. PUT/files/star.jpg와 같이 클라이언트가 직접 리소스의 URI를 지정한다. 이렇게 클라이언트가 관리하는 리소스 저장소를 스토어라고 한다. 

 

또한,  POST는 새로운 데이터를 계속 생성하기에 요청시마다 데이터를 생성하지만, PUT은 사용자가 데이터를 지정하고 수정하기 때문에 같은 요청을 계속해도 데이터가 중복되어 생성되진 않는다. 

 

 

 

📑 PATCH

 

PATCH는 PUT과 특징이 거의 비슷하지만 한 가지 중요하게 다른 점이 있다. 바로!! 리소스를 부분변경해준다. 위의 PUT의 사진에서 보면 원래 데이터엔 "username"과 "age"가 있었지만 요청 데이터에 "username"만 있었더니 전부 대체되어 age 속성값이 사라진 걸 확인할 수 있다. 하지만 PATCH를 사용하면 "age"는 그대로있고 바뀐 데이터만 변경된다. 

 

📌 PUT vs PATCH

 

위에서 말했듯이 PUT은 지정한 데이터를 전부 수정하지만, PATCH는 정보의 일부분만 변경해준다. 따라서 PUT은 멱등하지만, PATCH는 멱등하지 않다고 볼 수 있다. 그럼 멱등,,,?은 또 뭔데?? 아래에서 따로 설명하겠다. 

 

 

 

📑 DELETE

 

DELETE는 지정된 리소스를 제거한다. 제거하기 때문에 요청 시 Body와 Content-Type값이 비워져 있다. 물론 어떤 데이터를 삭제해야할지 식별해야 하므로 URL을 통해 어떤 데이터를 삭제할 지 파라미터를 받는다. 

 

 

 

📑 HTTP 메서드 속성

 

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

 

 

 

🔨 안전 (Safe)

 

: 안전이란? 호출해도 리소스를 변경하지 않는 것을 의미한다. 예를들어 GET으로 회원정보를 조회한다고 할때 이는 리소스의 변경이 일어나지 않으므로 안전하다고 할 수 있다. 하지만 POST를 이용해 회원가입을 한다고 할 때 리소스 변경이 일어나므로 이는 안전하지 않다고 볼 수 있다. 

 

 

🔨 멱등 (Idempotent)

 

: 멱등이란? 단어가 어렵기에 이해하기 어려울 수 있지만 한 번 호출하든 몇번 100번 1000번 호출하든 결과가 똑같다고 생각하면 된다. GET, PUT, DELETE는 여러번 같은 요청을 해도 결과가 똑같다. 하지만 POST는 멱등이 아닌데, 예를들어 음식을 주문한다고 할 때 여러번 요청이 들어가면 중복 결제가 발생할 수 있다. 

 

재요청 중간에 리소스가 변경된다면? 예를들어 나무위키같은 곳에서 내가 어떤 검색어를 입력해서 조회 후 게시글을 읽고 있는데 다른 사용자가 중간에 리소스르를 바꿀 수 있지 않은가?? 그럼 PUT도 멱등하지 않은 거 아닌가? 생각할 수 있지만 멱등은 외부 요인으로 중간에 리소스가 변경되는 것 까지는 고려하지 않는다.! 

 

 

 

🔨 캐시 가능 ( Cacheable)

 

캐시가능이란? 응답 결과 리소스를 캐시 ( 로컬 pc에 저장)해서 사용해도 되는가? 실제로 GET, HEAD 정도만 캐시로 사용한다. POST, PATCH는 본문 내용까지 캐시 키로 고려해야하기에 구현이 쉽지 않기 때문이다. 

 

REST의 특징으로 캐시가능이 있는데 이는, 대량의 요청을 효율적으로 처리하기 위해 캐시가 요구되며 캐시 사용을 통해 응답시간이 빨라지고 REST Server 트랜잭션이 발생하지 않기 때문에 전체 응답시간, 성능, 서버의 자원 이용률을 향상시킬 수 있다라는 특징이 있다. 

 

 

< 사용 예시 >

package hello.springmvc.basic.requestmapping;

import org.springframework.web.bind.annotation.*;

@RestController
@RequestMapping("/mapping/users")
public class MappingClassController {


    @GetMapping
    public String user(){
        return "get users";
    }

    @PostMapping
    public String addUser(){
        return "post user";
    }

    @GetMapping("/{userId}")
    public String findUser(@PathVariable String userId){
        return "get userId=" + userId;
    }

    @PatchMapping("/{userId}")
    public String updateUser(@PathVariable String userId) {
        return "update userId=" + userId;
    }

    @DeleteMapping("/{userId}")
    public String deleteUser(@PathVariable String userId) {
        return "delete userId=" + userId;
    }
}