[네트워크]HTTP 메소드와 멱등성

HTTP란?

HTML문서와 같은 리소스를 가져올 수 있도록 해주는 프로토콜이다. 클라이언트-서버 간 요청-응답 프로토콜로 수신자 측에 의해 요청이 초기화된다.

• 클라이언트가 서버에 HTTP 요청을 보내면 서버는 응답을 반환한다. 응답에는 요청에 대한 상태정보와 요청된 리소스를 포함할 수 있다.

클라이언트와 서버는 (데이터 스트림과 다르게) 개별적인 메시지 교환을 통해 통신한다.

HTTP 요청 메소드

HTTP는 요청 메소드를 정의해 주어진 리소스가 수행하길 원하는 행동을 나타낸다. 메소드들은 서로 다른 의미를 구현하지만, 일부 기능을 공유하기도 한다. 요청 메소드는 안전하거나, 캐시 가능하거나, 멱등성을 가질 수 있다.

• GET : 요청 URI에 의해 식별되는 모든 정보(엔티티)를 검색하는 것을 의미한다.(지정된 리소스에 데이터를 요청한다.)
• POST : 요청 URI에 의해 식별된 리소스의 새로운 항목으로 요청에 포함된 엔티티를 서버 측에서 수락하여 생성하도록 요청한다.(리소스를 생성/업데이트하기 위해 서버로 데이터를 보낸다.)

	GET	POST
데이터 전송, 보안, 길이 제한	URL에 요청정보(데이터)를 포함하여 요청하며, 데이터를 헤더에 포함한다. URL에 데이터가 노출되어 보안에 취약하다. 데이터를 URL에 포함해야 하므로 전송 길이의 제한이 있다.	URL에 요청정보(데이터)를 노출하지 않는다. 요청 헤더에 포함한 데이터의 타입이 명시된다. 데이터는 BODY에 포함되며 클라이언트 측에서 인코딩하여 전송하면 서버 쪽에서 디코딩하여 GET보다 보안이 안전하다. 전송 길이의 제한이 없어 대용량 전송에 적합하다.
캐싱	캐싱이 가능하여 GET방식으로 요청 시 캐싱되었던 데이터가 응답될 수도 있다.(보안 취약)	캐시를 지원하지 않는다.
조회	GET은 서버의 상태나 리소스의 변화가 없고, SELECT적 성향을 가지고 있다. 웹에서 모든 리소스는 링크될 수 있는 URL이 있고, 이를 이용해 원하는 페이지로 이동하거나 이동시킬 수 있는데 GET 방식은 해당 링크와 관려된 정보가 노출되어 있어 원하는 링크 정보를 받아올 수 있다.	요청 데이터가 BODY에 있어 링크 정보를 받아 올 수 없다.

 

• PUT : 요청 URI에 엔티티가 저장되도록 요청한다.(목적 리소스의 모든 현재 표시를 요청 페이로드로 바꾼다.) 이미 존재하는 리소스일 경우, 해당 엔티티가 수정되고, 새로운 리소스일 경우 서버는 해당 URI로 리소스를 생성할 수 있다.
  • POST와의 차이 : PUT은 멱등성이 성립한다. PUT 요청은 여러 번 호출해도 동일한 결과가 생성되지만, POST는 반복 호출 시 동일한 리소스가 여러 번 생성된다.
• DELETE : 요청 URI로 식별된 리소스를 서버 측에서 삭제하도록 요청한다.
• HEAD : GET메소드와 동일한 응답을 요구하지만, 응답에서 메시지 본문없이 헤더만 반환한다. HTTP 헤더에 포함된 메타 정보는 GET 요청에 대한 응답과 동일하다.
• CONNECT : 동적으로 터널로 전환할 수 있는 프록시와 함께 사용할 메서드 이름을 예약한다.(목적 리소스로 식별되는 서버로의 터널을 맺는다)
• OPTIONS : 요청 URI로 식별되는 자원에 대해 사용가능한 통신 옵션에 대한 정보 요청을 나타낸다.
  • 이를 통해 클라이언트는 리소스 작업을 암시하거나 리소스 검색을 시작하지 않고도 관련된 옵션 혹은 요구 사항을 결정할 수 있다.
• PATCH : PUT과 유사하나 PATCH는 리소스의 일부분을 수정한다.
  • 요청 시 일부분만 보낼 경우, PATCH은 기존값을 유지하지만, PUT은 default 혹은 null로 변경된다.

 

HTTP 멱등성

• 멱등성은 같은 행위를 여러번 수행해도 결과가 같다는 것을 의미한다.
  • GET : 여러 번 호출해도 클라이언트는 동일한 응답을 받음
  • POST : 여러 번 호출할 경우, 여러 열이 추가됨
• 동일한 요청을 한 번 보내는 것과 여러 번 연속으로 보내는 것이 같은 효과를 지니고, 서버의 상태도 동일하게 남을 때, 해당 HTTP 메서드가 멱등성을 가졌다고 말한다. 멱등성이 성립하는 메소드는 통계 기록을 제외하면 어떠한 side effect도 존재해서는 안된다.
  • 예를 들어 GET, HEAD, PUT, DELETE, OPTIONS는 같은 경로로 여러번 호출해도 결과가 같다. 그러나 POST, PATCH(다른 결과를 야기할 수도 있으나 PUT과 같은 방식으로 사용함으로써 멱등성을 가지게 할 수 있음), CONNECT는 그렇지 않다. 따라서, POST 등은 멱등성이 성립하지 않고, GET, PUT, DELETE 등은 멱등성이 성립한다.
  • PUT VS PATCH : PUT은 요청받은 값으로 해당 리소스를 대체하지만 PATCH는 일부만 수정한다. 예를들어 값을 명시하지 않고 증감하는 속성이 있는 경우, PATCH는 호출 할 때마다 리소스가 변경된다. 이 경우에는 멱등성이 성립하지 않는다.
• 멱등성을 따질 때에는 서버의 백엔드 상태만 보면 되며, 각 요청에서 반환하는 응답 코드는 다를 수 있다.
  • DELETE 요청의 상태 코드는 응답마다 달라지지만, side effect는 존재하지 않는다. (삭제 성공 - 200 / 데이터 없음 - 404)
• REST API에서 개발자는 DELETE메소드를 사용해 "목록의 마지막 항목을 제거하기" 기능을 구현해서는 안 된다.