: 서버에게 무엇을 해야할지 말해주는 것
- HTTP의 일곱가지 기본 메서드
| 메서드 | 설명 | (일반적으로) 본문 포함하는가? |
|---|---|---|
| GET | 서버에서 데이터를 가져옴 | X |
| POST | 서버에게 해당 데이터 처리를 요청 | O |
| PUT | 서버에 요청 메시지의 본문을 저장 | O |
| DELETE | 서버에서 데이터 제거 | X |
| HEAD | 서버에서 데이터에 대한 헤더를 가져옴 | X |
| TRACE | 메시지가 프락시를 거쳐 서버에 도착하는 과정 추적 | X |
| OPTIONS | 서버가 어떤 메서드를 수행할 수 있는지 확인 | X |
확장 메서드: 이외에도 서버마다 각 메서드를 추가로 구현해놓았을 수도 있음
LOCK(리소스 잠금), COPY(복사), MOVE(옮김) 등
이걸 사용할 땐 프록시 등 중간 매체는 모르는 메서드에 대해 관용적이어야 한다.
엄격하게 보내고 관대하게 받아들여라
마찬가지로, 모든 메서드가 다 구현되어있지 않을 수 있음.
안전한 메서드
: GET, HEAD. 이 두 메서드는 서버에 어떠한 변화(side effect)를 주지 않는다.
- 안전하지 않은 메서드 사용 시, 영향이 있을 수 있음을 사용자에게 알리도록 애플리케이션을 만들어야한다.
- e.g 경고 메시지
GET
- 초기에 (
HTTP/0.9까지) 이 메소드밖에 없었다. - 일반적으로 POST보다 빠르다. 일반적으로 브라우저 캐시나 프록시, 웹서버에 의해 캐싱되어 사용되기 때문
- 패킷이 가볍다: 본문이 없고, 때문에
content-type,content-length등 내용(content)에 관한 헤더 또한 없다.
HEAD
- 서버는 헤더만을 응답으로 돌려주고 엔티티 본문은 절대 반환되지 않는다.
- 리소스를 가져오지 않고도, 타입 등 정보를 알 수 있다.
- 리소스 존재 여부를 확인하고자 할 때
- 리소스 변경 여부 검사할 때
- 반환받는 응답 헤더가 반드시 GET과 정확히 일치해야 한다.
PUT
: 리소스 존재하면 수정. 리소스 없다면 만들어 저장하기도 함.
- 데이터 변경 가능성 있기 때문에 일반적으로 인증을 필요로 함.
POST
: 생성의 의미로 많이 쓰이지만, 원래는 서버에 입력 데이터를 전송(수행) 하기 위한 목적
- 서버는 전송받은 데이터를 처리할 서버 게이트웨이 프로그램에 전달한다.
HTTP/1.0에서 추가됨.- 일반적으로 멱등하지 않다.(계속 요청하면 계속 리소스 생성)
TRACE
: 어떤 경로로 서버까지 전달되었는지 추적. 진단의 목적
- 클라이언트의 요청은 방화벽, 프록시, 게이트웨이 등을 통해 서버까지 가고, 서버는 자신이 받은 요청 메시지를 본문에 넣어 TRACE 응답을 되돌려준다.
- 클라이언트가 보낸 메시지가 변조되었는지, 유실되었는지 등을 확인 가능
- 중간 애플리케이션들이 서로 다른 HTTP 메서드들에 대해 일관되게 다룬다고 가정하는 문제.
- 실제로 Proxy는
POST는 바로 통과,GET은 웹 캐시와 같은 애플리케이션으로 전송
- 실제로 Proxy는
OPTIONS
: 어떤 메서드가 지원되는지를 물어볼 때
- CORS의 preflight를 이거로 날려서 가능한지 확인
- 여러 리소스에 실제로 접근하지 않고도, 어떻게 접근하는게 최선인지를 확인 가능.
Reference)
HTTP 완벽 가이드