HTTP Method

< REST >

Representational State Transfer의 약자로 자원을 이름(자원의 표현)으로 구분하여 해당 자원의 상태(정보)를 주고받는 모든 것을 의미한다.

• 자원(Resource): URI
• 행위(Verb): HTTP Method
• 표현(Representations)

여기서 HTTP Method가 나오게 된다. 즉, REST를 지키면서 행위를 전달하는 방법이라고 생각하면 된다.

 

 

 

 

 

< HTTP Method >

메소드는 총 9개가 존재하며 아래와 같다.

• GET: 서버로부터 데이터를 취득
• POST: 서버에 데이터를 추가, 작성 등
• PUT: 서버의 데이터를 갱신, 작성 등
• DELETE: 서버의 데이터를 삭제
• HEAD: 서버 리소스의 헤더(메타 데이터의 취득)
• OPTIONS: 리소스가 지원하고 있는 메소드의 취득
• PATCH: 리소스의 일부분을 수정
• CONNECT: 프록시 등작의 터널 접속을 변경
• TRACE: 루프백 메시지를 호출하기 위해 테스트용으로 사용

HTTP Method	Request Has Body	Respone Has Body	safe	Idempotent	Cacheable
GET	Optional	Yes	Yes	Yes	Yes
HEAD	No	No	Yes	Yes	Yes
POST	Yes	Yes	No	No	Yes
PUT	Yes	Yes	No	Yes	No
DELETE	No	Yes	No	Yes	No
CONNECT	Yes	Yes	No	No	No
OPTIONS	Optional	Yes	Yes	Yes	No
TRACE	No	Yes	Yes	Yes	No
PATCH	Yes	Yes	No	No	No

 

 

 

 

 

< GET >

• GET 메소드는 주로 데이터를 읽거나(Read) 검색(Retrieve)할 때 사용되는 메소드이다.
• 만약 GET 요청이 성공적으로 이루어진다면 XML이나 JSON과 함께 200(Ok) HTTP 응답 코드를 리턴한다.
• 에러가 발생하면 주로 404(Not found) 에러나 400(Bad request) 에러가 발생한다.
• HTTP 명세에 의하면 GET 요청은 오로지 데이터를 읽을 때만 사용되고 수정할 때는 사용하지 않는다.
• GET 요청은 idempotent(멱등성) 하다.
• 같은 요청을 여러 번 하더라도 변함없이 항상 같은 응답을 받을 수 있다.
• 데이터를 변경하는 연산에 사용하면 안 된다.

GET /user/1

 

 

• 데이터를 조회하는 것이기 때문에 요청 시에 Body 값과 Content-Type가 비워져있다.
• 조회할 데이터에 대한 정보는 URL을 통해서 파라미터를 받고 있는 모습을 볼 수 있다.
• 데이터 조회에 성공한다면 Body 값에 데이터값을 저장하여 성공 응답을 보낸다.
• GET은 캐싱이 가능하여 같은 데이터를 한 번 더 조회할 경우에 저장한 값을 사용하여 조회 속도가 빨라진다.

 

 

 

 

 

< HEAD >

• HEAD는 각종 정보를 확인하기 위해 사용되는 메소드다.
• GET과 동일한 응답을 요구하지만, 응답 본문을 포함하지 않는다. (포함되더라도 이를 무시해야 한다고 한다.)
• HTTP 요청 시에도 GET 메소드는 헤더와 데이터를 서버에게 보내지만, HEAD 메소드는 헤더 정보 외에는 전송하지 않는다.
• 데이터 양이 줄어들기 때문에 빠르게 서버의 상태를 조회할 수 있다.
• 응답 헤더의 Content-Length 또한 동일하기 때문에 resource 양에 대한 조회만 할 때는 HEAD 메소드가 유용할 수 있다.

 

 

 

 

 

< POST >

• POST 메소드는 주로 새로운 리소스를 생성(create)할 때 사용된다.
• POST는 하위 리소스(부모 리소스의 하위 리소스)들을 생성하는 데 사용된다.
• 성공적으로 creation을 완료하면 201(Created) HTTP 응답을 반환한다.
• POST 요청은 idempotent(멱등성) 하지 않다.
• 같은 POST 요청을 반복해서 했을 때 항상 같은 결과물이 나오는 것을 보장하지 않는다.
• 두 개의 같은 POST 요청을 보내면 같은 정보를 담은 두 개의 다른 resource를 반환할 가능성이 높다.

POST /user
body: { data: "example" }
Content-Type: "application/json"

 

 

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

 

 

 

 

 

< PUT >

• PUT은 리소스를 생성/업데이트하기 위해 서버로 데이터를 보내는 데 사용된다.
• PUT 요청은 idempotent(멱등성) 하다.
• 동일한 PUT 요청을 여러 번 호출하면 항상 동일한 결과가 생성된다.
• PUT 메소드를 사용하는 클라이언트는 해당 자원의 상태를 모두 알고 있다고 가정되어야 한다.
• 요청 경로에 자원이 존재하는 경우 해당 자원을 payload 정보와 교체하는 메소드이다.
• 즉, PUT 메소드를 사용할 때 전송하는 payload만으로 자원의 전체 상태를 나타낼 수 있어야 한다.

PUT /user/1
body: { data: "update example" }
Content-Type: "application/json"

 

 

• 데이터를 수정하는 것이기 때문에 요청 시에 Body 값과 Content-Type 값을 작성해야 한다.
• 해당 예시는 JSON을 통해서 작성된 예시이다.
• URL을 통해서 어떠한 데이터를 수정할지 파라미터를 받는다.
• 그리고 수정할 데이터값을 Body 값을 통해서 받는다.
• 데이터 조회에 성공한다면 Body 값에 저장한 데이터값을 저장하여 성공 응답을 보낸다.

 

 

 

 

 

< PATCH >

• PATCH 메소드는 요청된 자원을 수정하기 위해 사용되는 메소드이다.
• 해당 자원 전체를 수정하는 PUT과는 다르게 PATCH는 해당 자원의 일부 부분을 수정한다.
• PATCH는 부분 수정을 위한 데이터만 요청의 payload로 보낸다.
• PUT은 idempotent(멱등성)을 지키지만 PATCH는 idempotent(멱등성)을 지키지 못한다.

PATCH /user/1

 

 

 

 

 

< DELETE >

• DELETE 메소드는 지정된 리소스를 삭제한다.

DELETE /user/1

 

 

• 데이터를 삭제하는 것이기 때문에 요청 시에 Body 값과 Content-Type 값이 비워져있다.
• URL을 통해서 어떠한 데이터를 삭제할지 파라미터를 받는다.
• 데이터 삭제에 성공한다면 Body 값 없이 성공 응답만 보내게 된다.

 

 

 

 

 

< 비교 >

> GET vs. HEAD

GET과 동일한 응답을 요구하지만, 서버 응답의 본문은 리턴되지 않고 HEAD 값만 넘겨오기 때문에 HEAD가 GET보다 속도가 빠르다.

 

> POST vs. GET

POST는 GET과 비교했을 때 URL에 데이터의 정보가 들어있지 않으므로 조금 더 안전하다고 볼 수 있다.

GET 방식은 캐싱을 하기 때문에 여러 번 요청 시 저장된 데이터를 활용하므로 조금 더 빠를 수 있다.

 

> POST vs. PUT

POST와 PUT은 구분해서 사용해야 한다. POST는 새로운 데이터를 계속 생성하기 때문에 요청 시마다 데이터를 생성하지만, PUT은 사용자가 데이터를 지정하고 수정하는 것이기 때문에 같은 요청을 계속하더라도 데이터가 계속 생성되지 않는다.

 

> PUT vs. PATCH

PUT은 지정한 데이터를 전부 수정하는 메소드지만, PATCH는 정보의 일부분이 변경되는 방법이다. 그래서 PUT은 멱등하지만, PATCH는 멱등하다고 볼 수 없다.