[HTTP] HTTP Method에 대해서 알아봅시다.

  Front-end 개발하면서 서버에서 제공해주는 RESTful API를 사용하게 됩니다. 최근에는 GraphQL과 같은 엔드포인트에서 Front가 요청하는 데이터를 객체 형태로 제공하는 방식도 있지만 현재 이 시점에서도 많이 사용되고 있는 HTTP Method에 대해 알아보겠습니다. HTTP Method는 Front-end라면 기본적으로 알아야 하며 서버측에서 데이터를 받아오는데 가장 기본이 됩니다.

 

  HTTP는 Request Method를 정의하여, 주어진 리소스에 수행하길 원하는 동작을 나타냅니다. 이 동작들을 HTTP Method라고 합니다. 각각의 메서는 서로 다른 구현하지만, 일부 기능은 메서드 집합 간에 공유되어지기도 합니다. 

 

 

GET(Read)

  서버에게 Resource를 보내도록 요청(Request)하는데 사용합니다. 요청을 통해 서버는 데이터를 '검색'하고 이를 클라이언트 측으로 보내줍니다. 즉, 클라이언트 측에서는 데이터를 가져온다. '읽어온다'라고 생각하면 됩니다.

 

 

 

 

HEAD

  GET Method와 동일한 동작을 하지만 서버에서는 이 요청에 따른 결과로 Body를 Return 하지 않습니다. 즉, 서버에 Resource를 가져오지는 않고 오직 응답코드(Status Code)만을 확인하기 위해서 사용합니다. 요청을 통해 응답의 상태 코드를 확인할 때, 서버의 응답 헤더를 봄으로써 Resource가 수정되었는지를 확인합니다.

 

 

 

 

PUT(Update)

  서버에 요청하여 새로운 데이터를 쓰기 위해서 사용합니다. GET의 방식과 반대라고 생각하면 됩니다. PUT 메소드는 서버가 Client 요청의 Body를 확인합니다. 그리고 요청된 URL에 정의된 새로운 Resource를 생성합니다. 주로 요청하는 URL이 기존에 존재할 경우에 대체하여 사용합니다. 따라서 현재 가진 데이터를 요청된 payload로 바꿉니다.

  단점으로는 기존 데이터를 교체하는 방식이므로 데이터를 변조하는 것이 용이합니다.

 

 

 

 

POST(Create)

  Server에 Data를 보내어 데이터를 생성합니다. 새로 작성된 리소스인 경우 HTTP Header에 `Location : URI 주소`를 포함하여 응답합니다.

 

PUT vs POST

그렇다면 PUT과 POST의 차이가 뭘까요?

  언뜻보면 두 메소드 모두 데이터를 쓴다는 방식으로 같은 동작을 하는 것 같습니다. 하지만 이 둘은 다른 용도를 가지고 있습니다.

 

- PUT은 UPDATE의 개념으로 사용되며 멱등하지 않습니다.

- POST는 INSERT의 개념으로 사용되며 멱등합니다.

즉, 동일한 자원을 여러번 POST하면 서버자원에는 변화가 생기지만, 여러번 PUT하는 경우는 변화가 생기지 않습니다.

 

  예를 들어 POST의 경우 클라이언트가 리소스의 위치를 지정하는 경우 사용됩니다.(/dogs) 따라서, 아래와 POST 요청이 여러번 수행되는 경우 매번 새로운 dog가 생성되어 dogs/3, dogs/4 등 매번 새로운 자원이 생성됩니다. 반면, PUT의 경우는 클라이언트가 명확하게 리소스의 위치를 지정합니다.(/dogs/3) 따라서, 아무리 많이 수행되더라도 리소스의 위치가 지정되어 새로운 자원이 생성되지 않으며 동일한 리소스(/dogs/3)를 수정하기만 하기 때문에 여러번 요청하더라도 멱등합니다.

 

 

 

 

DELETE(Delete)

  요청한 특정 Resource를 삭제하도록 요청합니다. 즉, PUT과 반대 개념입니다.

  그러나 HTTP 규격에는 Client의 요청에도 서버가 무효화 시킬 수 있도록 정의되어 있습니다. 따라서 DELETE Method는 항상 보장되지 않습니다.

 

 

 

 

TRACE

  Client로 부터 Request Packet이 방화벽, Proxy Server, Gateway등을 거치면서 packet의 변조가 일어날 수 있는데, 이때 Server에 도달했을 때의 최종 Packet의 Request Packet을 볼 수 있습니다. 즉 Resource의 경로(원격 서버)를 따라 메시지 loop-back 테스트 합니다.

 

 - 즉, Original Data와 서버에 도달했을 때의 비교본 Data를 서버의 응답 Body를 통해 확인 할 수 있습니다.

 - 요청의 최종 수신자는 반드시 송신자에게 200(OK) 응답의 내용(Body)으로 수신한 메세지를 반송해야 합니다.

 - 최초 Client 요청에는 Body가 포함될 수 없습니다.

 

 

 

 

OPTION

  Target Server의 지원 가능한 method(ex GET, POST, ...)를 알아보기 위합니다. 또는 Target Resource의 통신을 설정하는데 쓰입니다.

 

 

 

 

CONNECT

  Target Resource로 식별되는 서버로의 터널을 맺습니다.(터널링) 주로 웹 서버에 Proxy 기능을 요청할 때 사용됩니다.

 

 

 

 

PATCH

  Resource의 부분만을 수정하는데 사용됩니다.

 

PUT vs PATCH

  PUT는 해당 자원의 전체를 교체하는 의미를 가지며, PATCH는 일부를 변경한다는 의미를 가집니다. 때문에 최근 update 이벤트에서 PUT보다는 더 의미적으로 적합하다고 평가받고 있습니다. 또한 PUT의 경우는 멱등하지만, PATCH의 경우는 멱등하지 않습니다. PUT은 전체 자원을 업데이트 하기 때문에 동일자원에 대해서 동일하게 PUT을 처리하는 경우 멱등하게 처리됩니다. 반면 PATCH로 처리되는 경우 자원의 일부가 변경되기 때문에 멱등성을 보장할 수 없습니다.

 

 

 

 

HTTP 멱등성

  멱등(idempotent)의 의미는 같은 작업을 계속 반복해도 같은 결과가 나오는 경우를 의미합니다. 동일한 자원에 대한 GET 요청이라면 클라이언트에 반환되는 모든 응답은 동일해야 합니다. 특정 자원에 대한 DELETE의 경우도 자원은 더 이상 이용할 수 없어야 하며, DELETE 요청을 다시 호출한 경우도 자원은 여전히 사용할 수 없는 상태여야합니다.