본문 바로가기

네트워크

HTTP 메서드

반응형

GET

리소스 조회

서버에 전달하고 싶은 데이터는 query를 통해 전달

 

POST

요청 데이터 처리, 주로 등록에 사용

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

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

주로 전달된 데이터로 신규 리소스 등록, 프로세스 처리에 사용

(새 리소스 생성, 요청데이터 처리-단순히 값을 변경하는 것을 넘어 프로세스의 상태가 변경되는 경우, 다른 메서드로 처리하기 어려운경우-애매하면 post) 

get보다 캐싱하는데 오래걸림

서버가 아직 식별하지 않은 리소스 (서버가 새로 등록된 리소스 uri를 생성해줌)

 

PUT

리소스를 대체, 해당 리소스가 없으면 생성, 쉽게 이야기해서 덮어버림

클라이언트가 리소스 위치를 알고 uri지정->post와의 차이점

 

PATCH

리소스 부분 변경

 

DELETE

리소스 삭제

 

HEAD

GET과 동일하지만 메세지 부분을 제외하고, 상태 줄과 헤더만 반환

 

OPTIONS

대상 리소스에 대한 통신 가능 옵션을 설명

 

 

HTTP 메서드의 속성

1.안전 - GET, HEAD

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

2.멱등 - GET, HEAD, PUT, DELETE

f(f(x)) = f(x)

한번 호출하든 두번 호출하든 100번 호출하든 결과가 같음

=> 서버가 timeout등으로 정상응답을 못주었을 때, 클라이언트가 같은 요청을 해도 되는가? 판단 근거

3.캐시가능 - GET, HEAD, POST, PATCH(실제로는 GET, HEAD정도만 캐시로 사용, POST, PATCH는 본문까지 캐시키로 고려해야하는데 구현이 쉽지 않음)

응답 결과 리소스를 캐시해서 사용해도 되는가?

 

 

파일관리시스템에서 파일등록할 때 put씀-> 클라이언트가 리소스 uri를 알고 있어야하기 때문

 

FORM은 GET과 POST만 지원한다

그럴 때는 동사로 된 리소스 경로 사용(어쩔수 없이)

반응형

'네트워크' 카테고리의 다른 글

쿠키  (0) 2022.04.20
상태코드  (0) 2022.04.11
HTTP  (0) 2022.04.06
웹 브라우저 요청 흐름  (0) 2022.04.06
URI  (0) 2022.04.06