리소스를 조회할 때 사용하는 메서드
요청 시 필요한 데이터는 쿼리스트링를 통해서 전달한다. (동적 데이터 조회)
body를 사용해서 전달할 수는 있지만 서버에서 따로 구성을 해줘야한다.
조회 시 POST를 사용할 수도 있지만
설계원칙인 멱등성을 위반하기도 하고, GET은 캐싱이 가능하기 때문에
사용하지 않는다.
요청 데이터를 처리하는 메서드, 주로 등록할 때 사용한다.
요청 시 필요한 데이터들을 메세지(body)에 담아 전달한다.
만일 데이터를 GET 하는데 있어, JSON으로 조회 데이터를 넘겨야 하는 애매한 경우
POST를 사용한다.
리소스를 대체(덮어쓰기)한다.
해당 리소스가 없으면 생성한다.
데이터를 대체해야 하니, 클라이언트가 리소스의 구체적인 전체 경로를 지정해서 보내줘야한다.
POST /members
: 멤버 새로 추가
PUT /members/100
: 100번째 멤버 수정
만약 데이터의 속성 중 일부만 교체하려하는데
PUT
으로 교체하고자 하는 속성만 실어서 보내면
덮어씌워지기 때문에
나머지 속성들은 존재 자체가 삭제된다.
리소스를 부분 변경한다.
ex) 객체의 속성 값 중 일부만 수정
PUT
처럼 전체 속성을 다 담을 필요가 없다.
교체 대상 속성만 담아서 보내면 알아서 수정된다.
PATCH
를 지원하지 않는 서버에서는 POST 를 사용한다.
리소스를 삭제한다.
GET 과 동일하지만 메세지(Body) 부분을 제외하고 상태줄과 헤더만 반환한다.
즉, 서버에서 Body를 보내주지 않는다.
Resource를 받지 않고 찾기(존재 유무)만을 원할때 사용한다.
결과 값은 상태 코드로 알 수 있다.
대상 리소스에 대한 경로를 따라 메네시 루프백 테스트를 수행한다.
이 메서드로 HEAD처럼 검사용 메서드이다.
클라이언트의 요청 패킷이 방화벽, Proxy 서버, Gateway등을 거치면서
패킷의 변조가 일어날 수 있다.TRACE는 서버에 최종적으로 도달한 패킷의 내용을 응답 값을 받는다.
즉, 요청했던 패킷의 내용과 응답 패킷의 내용을 비교하면서 변조 유무를 확인할 수 있다.
요청시 Body를 포함할 수 없다.
대상 리소스에 대한 통신 가능 옵션(메서드)를 받아온다.
주로 CORS 에서 사용한다.
[Web] SOP와 CORS
대상 자원으로 식별되는 서버에 대한 터널을 설정한다.
HTTP TLS 터널링을 요청할때 사용한다.
HTML Form 태그는 GET과 POST 만 지원한다.
요청 시 body가 없는 메서드 :GET
HEAD
DELETE
TRACE