1. HTTP 메소드의 종류
메소드의 종류는 총 9가지가 있다. 메소드의 종류와 대략적인 용도를 알아보자
GET : 리소스를 조회한다.
POST: 데이터를 처리하는 요청을 보낸다.
PUT : 리소스를 대체한다. 해당 리소스가 없다면 생성한다.
PATCH: 리소스의 일부문 변경을 한다.
DELETE : 리소스를 삭제한다.
HEAD : 헤더정보만 조회한다. GET메소드에서 메세지 부분을 제외한 상태줄과 헤더만 반환한다.
OPTIONS: 대상 리소스에 대한 통신 가능 옵션을 설정한다. (주로 CORS에서 사용한다.)
CONNECT : 대상 리소스로 식별되는 서버에 대한 터널을 설정한다.
TRACE : 대상 리소스에 대한 경로를 따라 메시지 loop-back 테스트를 수행한다.
2. HTTP 메소드의 용도
- GET
보통 리소스를 조회할 때 사용한다. 서버에 전달하고 싶은 데이터는 쿼리 스트링을 통해서 전달된다.
바디를 사용해서 데이터를 전달할 수는 있지만, 지원하지 않는곳이 많아 권장하지 않는다.
요청시
응답시
- POST
데이터를 처리하는 요청을 보내고, 메세지의 body에 데이터를 담고 서버에 전달한다.
주로 신규 리소스를 등록할때나 프로세스 처리에 사용된다.
request의 body 타입은 헤더의 content-type 에 따라 결정된다.
요청
응답
- PUT
데이터를 덮어쓴다. 리소스가 있으면 대체하고 없으면 생성한다. 데이터를 수정할때 사용할 수 있다.
PATCH로 수정할 JSON의 일부분을 보낼 때, 해당 필드만 수정이 된다.
요청
응답
- PATCH
리소스를 수정할때 사용한다. PUT과 다른점은 PATCH는 리소스의 일부분만 변경이 가능하다는것이다.
put은 문서 자체의 교체만 허용한다. 또 PUT으로 수정할 JSON의 일부분을 보낼 때, 보낸 필드 이외에는 다 null이 된다.
요청 전 데이터
요청
응답
- DELETE
리소스를 제거할 때 사용한다.
요청
응답
- HEAD
헤더정보를 조회한다.
리소스를 가져오지 않아도, 그 리소스의 타입과 같은 정보를 알아낼 때 사용된다.
응답의 상태코드를 통해, 개체의 존재유무를 확인할 수 있다.
헤더만을 확인해 리소스의 변경 여부를 확인할 수 있다.
큰 용량의 리소스를 다운로드 받을지 말지 결정하기 위해서 사전요청하는 용도로 사용할 수 있다.
요청
응답
- TRACE
자신의 요청이 서버에 도달했을 때 어떻게 보이게 되는지 알려준다.
TRACE는 클라이언트에게 자신의 요청이 서버에 도달했을 때 어떻게 보이게 되는지 알려준다.
요청 전송의 마지막 단계에 있는 서버는 자신이 받은 요청 메세지를 body에 넣어 TRACE응답을 돌려준다.
이 단계에서 loop back 진단을 하는데 클라이언트는 자신과 목적지 사이에 있는 모든 HTTP 어플리케이션의 요청/응답을 따라가면서 자신이 보낸 메세지의 상태와 변경점을 확인 할 수 있다.
3.HTTP 메소드의 속성
메소드의 속성에는 3가지가 있다. 안전/ 캐시가능/ 멱등성(놀랍게도 오타가 아니다.)
- 안전(safe Methods)
안전 메소드를 구분하는 이유는 서버에 어떤 영향을 줄 수 있는 안전하지 않은 메소드가 사용될때,
사용자들에게 그 사실을 알려줄 수 있도록 하는 것이라고 한다.
계속해서 메소드를 호출해도 서버의 리소스는 변경되지 않는다. GET, HEAD, OPTIONS 가 안전한 메소드이다.
TRACE는 클라이언트 쪽에 공격을 시도하여 credentials을 훔칠수도 있기 때문에 안전하지 않다.
- 캐시 가능(Cacheable Methods)
캐싱을 하여 데이터를 효율적으로 가지고 올 수 있는 메소드들이다. GET, HEAD, POST, PATCH 가 캐시가 가능하다.
하지만 주로 쓰는 것은 GET과 HEAD라고 한다.
- 멱등성(Idempotent Methods)
동일한 요청을 한 번 보내는 것과 여러 번 연속으로 보내는 것이 같은 효과를 지니고, 서버의 상태도 동일하게 남을 때, 멱등성을 가졌다고 할 수 있다. GET 과 HEAD, PUT, DELETE, TRACE,OPTIONS 가 있다. 또 모든 안전한 HTTP 메소드는 멱등성을 가진다. POST와 PATCH는 아무리 같은 요청을 한다 해도 멱등성이 성립되지 않는다. 멱등성의 기준은 메소드를 실행 시킨 후의 서버의 상태이다. 상태 대신에 결과라고 생각해도 좋을 거 같다.
GET으로 조회를 100번 해도 조회된 리소스는 변하지 않는다. DELETE로 아무리 리소스를 지운다해도 서버에서는 해당하는 리소스가 지워진 상태라는 것이 변하지 않는다. PUT으로 수정을 해도 언제나 PUT 수정된 내용이 된다. 전체를 덮어쓰고 없으면 생성하기 때문이다.
GET방식으로 여러번 호출할 때 클라이언트가 받는 응답은 동일하다.
하지만 POST는 멱등성을 가지지 못한다. 여러번 호출되면, 여러열을 추가한다.
DELETE 의 상태코드는 응답마다 달라질 수는 있지만 그럼에도 멱등성을 가진다.
- 멱등을 구분하는 이유
네트워크상에서 요청을 했을때 요청이 실패할 때가 있을수 있다. 원인이 다양할 수 있는데, 이럴때 멱등성을 따지면 편하다. POST와 같은 속성이 요청이 어떤 원인으로 실패할때, 요청의 상태를 파악하지 않은 상황에서 재전송했을때의 요청이 처리가 되어선 안된다. 하지만 멱등 속성인 경우에는 서버의 리소스가 변하지 않으니 재전송 온 요청을 일단 처리하고 봐도 된다.
참고자료
http 메서드(꼭 가보는걸 추천한다.)
https://feel5ny.github.io/2019/08/16/HTTP_003_02/#5
멱등이란
https://irostub.github.io/web/idempotent/
멱등성이 그게 뭔데
멱등성 MDN 용어 사전
https://developer.mozilla.org/ko/docs/Glossary/Idempotent
상태코드와 메소드
'웹 > 네트워크 기본' 카테고리의 다른 글
| 네트워크란? , 통신의 종류는? (0) | 2022.03.10 |
|---|---|
| HTTPS 란 무엇일까 (0) | 2022.03.03 |
| http 란 무엇일까 (0) | 2022.02.13 |
| 이미지가 표시가 안될 때 (0) | 2020.11.09 |
| 네트워크 기초 (0) | 2020.11.09 |
