HTTP Method에 대해

Yi suho·2023년 3월 7일

네트워크

HTTP Method

주어진 리소스에 수행하길 원하는 행동, 서버가 수행해야 할 동작을 지정한다.

주요 메소드

GET

리소스의 조회에 사용한다.
서버에 전달하고 싶은 데이터를 query(parameter,query string)을 통해 전달한다.
메시지 바디를 통해 데이터를 전달할 수도 있지만 지원하지 않는 곳도 존재하기 때문에 권장 X

POST

메시지 바디를 통해 서버로 요청 데이터를 전달한다.

서버는 메시지 바디를 통해 들어온 데이터를 처리하는 모든 기능을 수행한다.

주로 신규 리소스의 등록,프로세스 처리 등에 사용한다.

ㄴ 신규 리소스를 등록했다면 새로 생성되었다는 201 상태 코드와 생성된 URI 경로(Location)를 반환한다.

또한, 다른 메소드로 처리하기 애매한 경우 주로 사용된다.조회할 때 데이터를 넘기기 어려운 경우 데이터를 넘기는 데 사용할 수 있지만

조회는 GET을 사용하는 것이 좋다.

POST는 캐싱하기 어렵기 때문

PUT

목적 리소스를 현재 메시지의 값으로 생성하거나 만약 존재한다면 기존 리소스를 삭제하고 덮어쓰기 한다.

POST와 PUT은 어떻게 구분해서 사용할까?

PUT은 POST와 다르게 클라이언트가 리소르의 위치를 알고 URI를 지정해 주어야 한다.

ex)PUT/members/100

PATCH

리소스를 부분적으로 변경한다.
지원하지 않는 경우도 있어 이런 경우 POST로 대체하여 사용

DELETE

특정 리소스의 삭제를 요청하는 데 사용

기타 메소드

HEAD : GET과 동일하지만 메시지 부분(body 부분)을 제외하고, 상태 줄과 헤더만 반환

OPTIONS : 대상 리소스에 대한 통신 가능 옵션(메서드)을 설명(주로 CORS에서 사용)

CONNECT : 대상 자원으로 식별되는 서버에 대한 터널을 설정

TRACE : 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행

HTTP 메소드의 속성

안전한 메소드 (Safe Method)

안전한 메소드란, 서버의 상태를 변경시키지 않는 HTTP 메소드를 의미한다.
GET,OPTIONS,HEAD 와 같이 조회에 사용되는 메소드를 안전하다고 이야기 할 수 있다.
모든 안전한 메소드는 멱등성을 갖지만 , 그 역은 성립하지 않는다.

PUT 과 DELETE 메소드는 멱등성을 갖지만,
PUT은 리소스를 수정하고,DELETE는 메소드를 제거하므로 안전한 메소드라고 이야기할 수 없다.

즉,멱등성을 갖는 메소드가 서버의 상태를 변경하지 않는다고 오해하면 안된다.
멱등성을 갖는 메소드도 서버의 상태를 변경시킬 수 있다.
멱등성의 핵심은 "요청에 대한 서버의 상태가 항상 같은가?" 이다.

호출해도 리소스를 변경하지 않는 특성이다.

멱등성 Idempotent

동일한 요청을 여러 번 보내도 한번 보내는 것과 같은 것
외부 요인으로 중간에 리소스가 변경되는 것을 고려하지 않고 해당 요청을 기준으로 고려한다.
올바르게 구현한 GET,PUT,DELETE 메소스는 멱등성을 지녀야 한다.

ex)

DELETE /members/100 → 200
DELETE /members/100 → 404
DELETE를 여러 번 호출하면 응답 코드는 달라질 수 있지만, 100번 member가 삭제된 것은 동일

HTTP Method 의 멱등성

-동일한 요청을 한번 보내는 것과, 여러번 보내는 것이 서로 동일한 효과를 지니고,서버의 상태도 동일하게 남을 때 해당 HTTP Method 가 멱등성을 갖는다고 이야기 한다.
멱등성을 따질 때에는 서버의 상태만 바라보면 되며,HTTP 응답 Status는 신경쓰지 않아도 된다.

올바르게 구현되 REST API 의 GET,HEAD,OPTIONS,PUT,DELETE 메소드는 통계 기록(e,g 게시물 조회수의 증가 등)을 제외 하였을 경우 멱등성이 보장된다.

GET: 서버에 존재하는 리소스를 단순히 읽어오기만 하는 메소드이기 때문에 당연히 여러번 수행되어도 결과값은 변하지 않는다.
마찬가지로 HEAD,OPTIONS 메소드도 조회에 대한 메소드이기 때문에 멱등하다고 할 수 있다.
PUT:서버에 존재하는 리소스를 요청에 담긴 내용대로 통째로 대체해버리므로 올바르게 구현 하였다면 여러번 수행되어도 결과 값은 변하지 않을 것이다.
DELETE: 존재하는 데이터를 삭제한 경과와 이미 존재하지 않은 결과를 삭제하려는 시도에 대한 응답 코드는 서로 다르겠지만,(200 OK 또는 404 NOT FOUND) 서버의 상태 자체는 변하지 않으므로 올바르게 구현되었다면 여러번 수행되어도 멱등성이 보장될 것 이다.

하지만 ,POST는 이야기가 다르다.
POST 메소드가 호출될 때 마다 데이터베이스 등에 요청된 데이터가 추가될 것 이고,이는 곧 멱등성을 위배함을 알 수 있다.
호출시 마다 서버의 상태가 달라지기 때문이다.

PATCH 메소드는 항상 멱등성을 보장한다고 이야기 할 수 없다.
정확히는 PATCH는 멱등성을 보장하도록 설계할 수 있지만,멱등성을 보장하지 않도록 설계할 수도 있다.
PUT은 요청에 대하여 리소를 통째로 바꿔버리기 때문에 멱등성이 보장되지만,PATCH는 리소스의 일부에 대하여 변화를 명령할 수 있기 때문이다.

캐시 가능성 Cacheable

캐시 가능성은 응답 결과 리소스를 캐싱해서 효율적으로 사용할 수 있는가 에 대한 여부이다.

캐시(Cache)가 꼭 운영체제나 서버에만 있는 것이 아니라, 브라우저 자체도 하나의 소프트웨어라 캐시 공간을 가지고 있는데, 클라이언트가 서버에 한 번 요청했던 데이터에 대해 매 요청마다 다시 전송할 필요가 없도록 브라우저가 임시적으로 데이터를 보관하고 있는 장소이다.

응답 결과를 서버에 캐시 해서 사용해도 되는 메소드
GET,HEAD,POST,PATCH가 가능하지만 실무에서는 구현이 어렵기 때문에(POST와 PATCH는 지원 되지 않는 경우가 일반적이라고 한다.) GET,HEAD 정도만 캐시 하여 사용
ㄴ 브라우저의 캐시를 이용하려면 원본 데이터가 변경되지 않고 유지되어야 하는데,POST,PUT,DELETE,PATCH 는 기본적으로 데이터 변경이 되는 메서드 이기 때문에, 만일 호출로 인해 데이터가 변경되게 되면 원본 데이터 또한 변경되기 때문에 캐시 데이터 불일치 문제가 생기기 때문이다.

반면 GET은 딱 URI만 키로 잡고 캐시하면 되서 간단하다.

따라서,GET,HEAD 메서드는 캐시가 가능하기 때문에 브라우저에서 리소스를 임시로 보관할 수 있고,나머지 메서드들은 구현의 복잡성 혹은 유지의 어려움 때문에 캐시를 이용하지 않는다고 생각하면 된다.

출처 https://girawhale.tistory.com/66
https://hudi.blog/http-method-idempotent/
https://inpa.tistory.com/entry/WEB-%F0%9F%8C%90-HTTP%EC%9D%98-%EB%A9%B1%EB%93%B1%EC%84%B1-%C2%B7-%EC%95%88%EC%A0%95%EC%84%B1-%C2%B7-%EC%BA%90%EC%8B%9C%EC%84%B1-%F0%9F%92%AF-%EC%99%84%EB%B2%BD-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0