jongviet

Aug 1, 2021 - HTTP 구조(req, res) / HTTP 메소드(get, post, put, patch, delete) / HTTP 메소드 속성(안전, 멱등, 캐시가능) 본문

Http

Aug 1, 2021 - HTTP 구조(req, res) / HTTP 메소드(get, post, put, patch, delete) / HTTP 메소드 속성(안전, 멱등, 캐시가능)

jongviet 2021. 8. 1. 17:02

*8월1일


*HTTP 구조
-요청 메세지와 응답 메세지 구조가 다름.
-200 성공 / 400 클라이언트 요청 오류 / 500 서버 내부 오류 등 기본 응답 코드
-HTTP 헤더에는 HTTP 전송에 필요한 모든 부가 정보가 다 들어 있음; 메세지 내용 및 크기, 압축, 인증, 요청 클라이언트 브라우저 정보, 서버 애플리케이션 정보 등등; 필요한 메타 데이터 정보가 다 있다고 보면 됨.
-HTTP 바디에는 실제 전송할 데이터가 있음. HTML문서, 이미지, 영상, JSON 등 byte로 표현할 수 있는 모든 데이터가 전송 가능함.
-단순하고 확장 가능함.


일반구조
시작라인
헤더
공백라인(CRLF)
바디

요청메세지 구조
GET/search?a=b&c=d HTTP/1.1
Host: www~~
공백라인

응답메세지 구조
HTTP/1.1 200 OK
Content-type: text/html; charset=UTF-8; Content-length: 3423
공백라인
<html>
<body></body>
</html>

*HTTP 메소드
-회원 API 설계 기준
-가장 중요한 것은 리소스 식별!!? -> /members/{id} 와 같은 설계 권장
-URI는 리소스에 매칭해서 설계 해야함, 따라서 리소스와 행위를 분리하는게 맞음.
-행위는 HTTP 메소드가 처리 해줌!
-resource = representation(최근 term임!)

get : 리소스 조회
post : 요청 데이터 처리, 주로 등록에 사용
put : 리소스를 대체, 해당 리소스가 없으면 생성  //파일
patch : 리소스 부분 변경 //회원 필드 수정
delete : 리소스 삭제
head : get과 동일하지만 body를 제외하고 상태줄과 헤더만 반환

1)get
-리소스 조회
-서버에 전달하고 싶은 데이터는 query를 통해 전달
-메시지 바디를 이용해서 데이터를 전달 할 수 있지만, 지원하지 않는 곳이 많아서 비권장.

2)post
-메세지 바디를 통해서 서버로 요청 데이터 전달 / 서버는 요청 데이터 처리
-주로 전달된 데이터로 신규 리소스 등록 or 프로세스 처리에 사용
-HTML form으로 넘어온 데이터 처리 / 게시판 글쓰기, 댓글 달기 / 신규 회원가입, 신규 주문 생성 / 기존 자원에 데이터 추가
-추가적으로 요청 데이터 처리에도 사용함(프로세스 처리); 즉, 결제완료 -> 배달시작 -> 배달완료처럼 단순한 값 변경을 넘어 프로세스의 상태가 변경되는 경우
-/orders/{orderid}/start-delivery
-추가적으로 다른 메서드로 처리하기 애매한 경우에 post를 사용함.
-post는 모든 것을 할 수 있음!!!
-단순 조회는 get으로 하는게 맞음. 데이터변경/프로세스변경/어쩔수없는 경우 post

3)put
-리소스가 있으면 대체/없으면 생성, 쉽게 얘기하면 덮어쓰기
->완전한 대체 : 이름/나이만 있는 상태에서 나이만 보내면 나이만 대체되어서 남음.. name 필드는 삭제됨.
-클라이언트가 리소스 위치를 알고 URI 지정
-파일 등록/이미지 등록
-리소스 수정이 아니라 기존 리소스를 갈아 치우는 개념!

4)patch
-리소스 부분 변경
-특정 부분만 변경 하는 것
-patch가 지원 안되는 경우에는 post를 쓰면 됨.

5)delete
-리소스 제거


*HTTP 메소드 속성

-안전 / 멱등 / 캐시가능

1)안전이란, 호출해도 리소스를 변경하지 않음. 호출해서 무언가 변경이 일어나는 것은 안전하지 않은 것 취급.

2)멱등(idempotent) :  연산을 여러 번 적용하더라도 결과가 달라지지 않는 성질. 즉, 한번 호출하든 두 번 호출하든 100번 호출 하든 결과가 똑같다.

-get은 여러번 조회해도 같은 결과가 조회됨.
-put은 결과를 대체하기에 같은 요청을 여러번 해도 결과가 같다.
-delete는 결과를 삭제하기에 같은 요청을 해도 삭제된 결과는 같다.
-post는 멱등이 아니다. 두 번 호출하면 같은 결제가 중복해서 발생 할 수 있음.
->자동복구 매커니즘, 서버가 timeout 등으로 정상 응답을 주지 못했을 때, 클라이언트가 같은 요청을 다시 해도 되는가에 대한 판단 근거가 멱등!!
-재요청 중간에 다른 곳에서 리소스를 변경한다면? 멱등은 외부 요인으로 중간에 리소스가 변경된 것까지는 고려하지 않는다. 

3)캐시가능(cacheable)

-응답 결과 리소스를 캐시해서 사용해도 되는가? get,head,post,patch가 가능하며, 실제로는 get,head정도만 캐시로 사용함. post,patch는 본문 내용까지 캐시로 고려해야해서 구현이 쉽지 않음. 
-캐시란 로컬에 저장해놓고, 바로 열어보는 개념. 지워질 수 있다는 것을 전제로 사용하고, 데이터양이 많지 않은 것이 좋다 왜냐하면 캐시가 붙은 장치는 비쌈~

'Http' 카테고리의 다른 글

Aug 4, 2021 - HTTP header, Cookie  (0) 2021.08.04
Aug 3, 2021 - HTTP 상태 코드, PRG, Redirection  (0) 2021.08.03
Aug 2, 2021 - HTTP API(= RESTful API), API URI 설계  (0) 2021.08.02
Aug 1, 2021 - TCP/IP, UDP, Port, DNS, URI, HTTP1.1, 2,3, Stateless & Stateful, 비연결성  (0) 2021.08.01
July 28, 2021 - HTTP 인프런 강의 구매  (0) 2021.07.28
'Http' Related Articles more
Comments