HTTP 메소드

HTTP에는 메소드라는것이 존재한다. 대표적으로 GET, POST, PUT, DELETE 등이 있다.

 

 

메소드별로 쓰임새가 있는데 HTTP API를 만들 때 행위를 구분하기 위해 사용할 수 있다.

 

 

예를 들어 게시판에 글을 조회하는 API와 게시글을 삭제하는 API를 만든다고 했을 때 URI를 이렇게 만들 수 있을 것이다.

@GetMapping("/boards/{id}")
public String search() {
	return "board";
}

@DeleteMapping("/boards/{id}")
public String delete() {
	return "boardList";
}

두 API의 URL을 보면 동일하게 /boards/{id}로 되어있는 것을 볼 수 있다. 이렇게 동일한 URL에서 용도를 구분하는 방법 중 하나가 바로 HTTP메소드의 사용이다.게시글을 조회하는 기능에는 GET메소드를 사용하였고, 게시글을 삭제하는 기능에는 DELETE메소드를 사용하였다.

 

이렇듯이 HTTP메소드는 각자 사용용도가 있다.

 

HTTP메소드의 종류로는 크게 5가지를 볼 수 있다.

• GET : 리소스 조회
• POST : 요청 데이터 처리, 주로 등록에 사용
• PUT : 리소스를 대체, 해당 리소스가 없으면 생성
• PATCH : 리소스 부분 변경
• DELETE : 리소스 삭제

 

이 외에도 몇 가지 메소드들이 더 있지만 자주 사용하지 않으므로 다루지는 않겠다.

 

 

 

 

GET

GET메소드는 리소스를 조회하는데 사용한다.

 

일반적으로 페이지를 조회하는데 사용하는 메소드가 GET메소드이다. 데이터를 전달할 때는 message body가 아니라 쿼리 파라미터의 형태로 전달한다.

https://www.google.com/search?q=http&oq=http

 

google.com/search? 뒤에 붙은 내용을 쿼리 파라미터라고 부른다.

 

? 뒤에 위치하며 &를 이용해서 여러개를 붙일 수가 있다. 저렇게 쿼리 파라미터로 URI를 만들어서 요청을 보내면 서버에서는 HttpServletRequest를 이용해서 데이터를 받아올 수있다.

 

message body에도 데이터를 직접 넣을 수는 있지만 통상적으로는 그렇게 사용하지 않고 있기때문에 쿼리 파라미터를 이용해서 데이터를 넘기는 것이 좋다.

 

 

 

 

POST

POST를 흔히들 저장하는 용도의 메소드라고 알고있는 경우가 있다. 물론 저장의 용도로 많이 사용하기는 하지만 사실 그 외에도 많은 것들을 할 수 있는 메소드이다.

 

POST의 정확한 역할은 서버로 넘어온 데이터를 처리하는 모든 일에 가능하다. 데이터를 저장하거나 수정하거나 삭제하는것 외에도 내부적으로 복잡하게 처리하는 것까지 모든 것을 할 수 있는 것이 바로 POST이다.

 

POST의 특징 중 하나로는 Resource를 정확하게 몰라도 가능하다는 것이다.

 

예를 들어 게시글을 새로 생성한다고 했을 때 'POST /board' 라는 URI를 서버로 전송했을 때 서버는 해당하는 URI를 찾아서 게시글을 만든 뒤 응답메세지에 '/board/5 201 Created'와 같이 보낼 것이다.

 

이 처럼 서버로 보낼 때는 구체적인 Resource를 모른채 /board라고 보냈지만 돌아오는 응답은 게시글의 번호까지 포함된 구체적인 Resource를 받게 된다.

 

그리고 POST로 데이터를 넘길떄는 JSON을 많이 사용한다. GET과 같이 쿼리 파라미터로 넘길 수도 있지만 POST로 넘기는 데이터는 중요한 데이터를 다루는 경우가 많기 때문에 보안의 이유로 쿼리 파라미터는 사용하지 않는 것이 좋다.

 

필요한 경우에는 GET의 역할도 할 수 있지만 각 메소드마다의 역할이 있다는 것은 통신에 대한 약속이 있는 것이기 때문에 정말 어쩔 수 없는 경우가 아닌이상 역할에 맞는 메소드를 사용하는 것이 좋다.

 

 

 

 

PUT

PUT은 Resource를 완전히 대체하는 메소드이다. 쉽게 이해하기 위해서 디렉터리(폴더)안에 파일을 집어넣는 과정이라고 생각하면된다.

 

폴더안에 파일을 넣을 때 해당하는 파일이 없다면 파일이 그대로 들어갈 것이고 파일이 존재한다면 파일이 통째로 변경될 것이다. 이 처럼 부분 대체가 아닌 완전한 대체가 PUT메소드의 핵심이다.

 

그리고 PUT은 POST와 다르게 Resource의 정확한 위치를 알고 있다.

 

/board/5와 같이 정확한 Resource를 보내주어야 한다.

 

이제 데이터를 보내는 예시를 만들어보자.

{
	"title" : test,
	"content" : put test
}

json형식의 다음과 같은 데이터를 'PUT /board/7'의 URI로 보낸다고 생각해보자.

 

만약 서버에 이미 7번을 가진 게시글이 존재한다면 title과 content의 내용을 위의 데이터로 완전히 교체할 것이다. 반대로 서버에 데이터가 존재하지 않는다면 7번의 번호와 위의 데이터를 가진 게시글을 추가하게 될 것이다.

 

 

위와같이 Resource를 PUT메소드로 담아서 전송시키면 서버에서는 해당하는 URI가 존재한다면 해당 Resource를 전송받은 것으로 완전히 바꿔버린다.

만약 요청 URI의 Resource가 서버에 없다면 새로 생성될 것이다.

 

 

만약 title을 공백으로 하고 content값만 보내도 부분대체가 아니라 완전 대체가 이루어진다.

{
	"content" : put test
}

이런 형식으로 위와 같은 URI로 데이터를 보낸다면 기존에 존재하던 데이터에서 title이 없어지고 content의 내용만 존재하게 될 것이다. 한마디로 부분 수정은 불가능한 것이다.

 

그렇다면 항상 모든 값을 채워넣어서 요청을 보내야하는가 했을 때 이 문제를 해결하기 위해서 PATCH메소드를 사용한다.

 

 

 

 

PATCH

PATCH메소드는 PUT메소드만 존재하던 시절에 부분 수정에 대한 불편함을 해소하기 위해서 생긴 메소드이다.

 

이 메소드는 PUT메소드와 비슷하지만 요청에 보낸 Resource만 부분대체를 할 수 있다.

 

{
	"content" : put test
}

이런 데이터를 전송해도 기존에 title의 내용은 유지한 채 content의 내용만 변경할 수 있다.

 

아직 PATCH메소드를 지원하지 않는 서버가 존재할 수 있으므로 그런 경우에는 POST를 사용해서 전송하면 된다.

 

 

 

 

DELETE

서버에 존재하는 Resource를 삭제하고 싶다면 DELETE메소드를 사용하면 된다.

 

PUT과 같이 구체적인 URI를 지정해주어야 한다.

 

 

 

 

HTTP 메소드 특징

메소드의 특징으로는 크게 3가지가 존재한다.

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

 

(1) 안전(Safe Methods)

안전은 말 그대로 메소드가 안전한가를 보는 메소드이다.

 

GET메소드와 같이 요청을 보내도 Resource가 변하지않는 메소드를 안전한 메소드라고 한다.

 

그리고 POST, PUT, PATCH, DELETE등과 같이 요청시 Resource값이 조금이라도 변할 수 있는것들을 안전하지 않은 메소드라고 한다.

 

 

(2)멱등(Idempotent Methods)

메소드를 몇 번을 호출해도 결과값이 똑같은 것을 '멱등하다' 라고 이야기한다.

 

예를 들어 GET은 조회를 하는 메소드이기 때문에 당연히 몇 번을 조회해도 결과 값이 바뀌지 않는다.

 

PUT, DELETE의 경우도 처음 요청했을 떄의 결과와 2,3번 요청했을 때의 결과는 동일할 것이다. 수정된 것은 똑같이 수정되고 삭제된 것은 계속 삭제된 상태이기 때문이다.

 

하지만 POST의 경우는 다르다.

만약 게시글을 생성하기 위해 POST를 이용해서 보냈다면 2,3번 요청했을 때는 요청한 만큼의 게시글이 생성되기 때문에 결과값이 일정하지 않다. 이런 경우를 '멱등하지 않다'고 이야기한다.

 

멱등의 여부는 다른 개입이 없이 순수하게 그 메소드를 여러번 호출했을 떄를 생각해야한다.

 

예를 들어, GET요청을 한 후 2번째 요청을 하기전에 PUT요청에 의해서 데이터가 변경된다면 GET의 2번째 요청에는 결과가 달라질 수도 있다. 이렇듯 멱등의 여부를 판단하고자하는 것 외에 다른 개입이 전혀 없다라는 가정으로 멱등의 여부를 판단해야 한다.

 

멱등을 활용하는 경우로는 '자동 복구 매커니즘'이 있다.

 

서버가 요청을 받아서 요청은 처리했는데 중간에 문제가 생겨서 클라이언트에게 응답을 해주지못할 경우가 생길 수 있다. 이때 클라이언트가 같은 요청을 다시해도 되는지 안되는지의 여부를 파악해야한다. 이것을 판단하는 근거를 멱등에서 찾을 수 있다.

 

 

(3) 캐시가능(Cacheable Methods)

이름 그대로 캐시가 가능한가에 대한 내용이다.

 

HTTP메소드 중에서 캐시가 가능한 메소드는 GET, HEAD, POST, PATCH가 있다.

하지만 POST와 PATCH의 경우는 message body의 내용도 캐시를 해야하기 때문에 구현이 쉽지 않다는 문제가 있다.

 

 

그래서 실질적으로는 GET과 HEAD정도만 캐시를 사용하고 POST와 PATCH는 잘 사용하지 않는 편이다.