HTTP 메세지 & 메서드

요청 메세지

 

종류 : GET, POST, PUT, DELETE

GET : 리소스 조회

POST : 요청 내역 조회

---

응답 메세지

 

HTTP 상태 코드 : 요청 성공, 실패를 나타냄

200 성공

400 클라이언트 요청 오류

500 서버 내부 오류

이유 문구 : 사람이 이해할 수 있는 문구 

 

OWS 띄어쓰기 허용

 

HTTP 헤더

용도 : HTTP 전송에 필요한 모든 부가정보 

예) 메세지 바디의 내용, 크기, 압축 인증, 클라이언트 정보 등등

 

HTTP바디

실제 전송할 데이터

HTML 문서,이미지,JSON 등등 byte로 표현할 수 있는 모든 것

---

🔴HTTP 메서드

리소스 : 핵심 개념 자체가 리소스 

핵심 개념 자체만 식별하면 됨 > 리소스를 URI에 매핑

GET : 리소스 조회
POST : 요청 데이터 처리, 주로 등록에 사용
PUT : 리소스를 대체, 해당 리소스가 없으면 생성
PATCH : 리소스 부분 변경
DELETE : 리소스 삭제 


HEAD :  GET과 동일하지만 메시지 부분을 제외하고, 상태 줄과 헤더만 변환
OPTIONS : 대상 리소스에 대한 통신 가능 옵션을 설명

 

!GET

query를 통해서 전달

조회할 때는 GET이 유리

 

!POST

대상 리소스가 리소스의 고유한 의미 체계에 따라 요청에 포함된 표현을 처리하도록 요청

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

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

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

EX) HTML양식에 입력된 필드와 같은 데이터 블록을 데이터 처리 프로스세스에 제공

       게시판, 뉴스 그룹, 메일링 리스트 등.., 서버가 아직 식별하지 않은 새 리소스 생성, 기존 자원에 데이터 추가

다른 메서드로 처리하기 애매한 경우에도 POST 활용

 

!PUT

리소스가 있으면 완전히 대체, 리소스가 없으면 생성

클라이언트가 리소스 위치를 알고 URI를 지정

 

!PATCH

리소스 부분 변경

 

!DELETE

리소스 제거

---

🟢HTTP메서드 속성

 

안전(SAFE) : 호출해도 리소스를 변경하지 않는다 (해당 리소스마나 고려, 로그 쌓여서 장애같은건 고려하지 않음)

 

멱등(IDEMPOTENT) 몇 번을 호출해도 결과가 같아야 함 > POST! 멱등이 아님, 두번 호출하면 중복결제 가능성 있음

> 자동 복구 메커니즘 활용 가능성 

Q.재요청 중간에 다른 곳에서 리소스를 변경해버리면? A. 외부 요인으로 중간에 리소스 변경되는 것 까지는 고려하지 않음

 

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

실제로는 GET,HEAD정도만 개시로 사용

POST,PATCH는 본문 내용까지 캐시 키로 고려해야 하는데 구현이 쉽지 않음