[강의] 모든 개발자를 위한 HTTP 웹 기본 지식 2

호다닥

https://inf.run/zu13

모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 | 강의

 

3. HTTP 기본

- 모든 것이 HTTP

HTTP 메세지로 거의 모든 것을 전송할 수 있다.

 

현재 주로 사용하는건 HTTP/1.1 TCP기반이다. 2, 3도 증가하는 추세긴 함

 

HTTP특징

클라이언트 서버 구조

무상태 프로토콜(스테이스 리스), 비연결성

HTTP 메시지

단순함, 할당 가능

 

- 클라이언트 서버 구조

클라이언트는 서버에 요청을 보내고, 응답을 대기한다.

 

클라이언트와 서버를 분리하는 것이 중요한다.

비즈니스 로직, 데이터는 서버

UI, 사용성 클라이언트

분리하면 양쪽이 독립적으로 진화할 수 있다.

 

- Stateful, Stateless

Stateful : 상태 유지

Stateless : 무상태 - 방금 한 말 기억하지 못하는 사람과 대화 문맥 x

하지만! 앞 정보를 계속 알려주면서 대화한다.

 

=> 응답 서버를 쉽게 바꿀 수 있다.

무한한 서버 증설 가능(Scale out), 중간에 서버가 꺼져도 다른 서버에 호출 가능

 

따라서, 최대한 무상태를 사용한다.

상태 유지를 사용해야만 하는 경우(로그인 등) 제외

단점 : 데이터 양이 좀 많다.

 

- 비 연결성(connectionless)

필요한 데이터 주고 받으면 연결 끊어버림

수천명이 사용해도 실제 서버에서 동시에 처리하는 요청은 수십게 이하로 매우 적음

->효율적으로 사용할 수 있다.

 

하지만,

TCP/IP연결을 매번 새로 맺어야함 - 3 way handshake 시간 추가

웹 브라우저로 사이트를 요청하면 수많은 자원을 매번 다운로드 해야 된다

->극복 : HTTP 지속 연결

 

정말 같은 시간에 딱 맞추어 발생하는 대용량 트래픽 경우에는 의미가 없다

-> stateless를 기억하자

 

- HTTP 메시지

start-line(시작 라인)

start-line = request-line/ status-line

HTTP 요청 메시지 

request-line = [HTTP메서드] [/ 요청 대상(절대경로)] [HTTP 버전]

HTTP 응답 메시지

status-line = [HTTP 버전] [상태 코드] [reason-pharse(상태 코드를 나타내는 사람이 읽을 수 있는 글)]

상태 코드 - 200 성공 400 클라이언트 요청 오류 500 서버 내부 오류

 

header(HTTP 헤더)

header-field = [필드 이름(대소문자 구분 x):] (OWS)[필드값](OWS) 

필드 이름과 :는 꼭 붙어야 함 나머지는 띄어쓰기 상관 x

HTTP 전송에 칠요한 모든 부가 정보

 

message body(HTTP 메시지 바디)

실제 전송할 데이터

 

HTTP는 단순하고 확장이 가능하다

 

2. HTTP 메서드

- HTTP API를 만들어보자

URI에 가장 중요한 것 - 리소스 식별

리소스와 해당 리소스를 대상으로 하는 행위(메서드)를 분리한다.

ex) 리소스 : 회원 , 메서드 : 조회, 수정 ...

 

- HTTP 메서드 - GET, POST

<주요 메서드>

GET : 리소스 조회

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

PUT : 리소스를 대체, 해당 리소스가 없으면 생성

PATCH : 리소스 부분 변경

DELETE : 리소스 삭제

 

GET

리소스 조회

서버에 전달하고 싶은 데이터는 query로 전달.

 

POST

요청 데이터 처리

메시지 바디를 통해 서버로 요청 데이터 전달->서버는 요청 데이터를 처리

1. 새 리소스 생성 신규 리소스 등록 

2. 프로세스 처리에 사용 요청 데이터 처리

3. 다른 메서드로 처리하기 애매한 경우

ex)게시판 글쓰기, 폼 입력 데이터 처리, 신규 주문 생성, 기존 자원에 데이터 추가 등

 

- HTTP 메서드 - PUT, PATCH, DELETE

PUT 

리소스를 대체

리소스가 있으면 대체/ 없으면 생성 => 완전히 대체, 덮어버림

클라이언트가 리소스를 식별한다는 점이 가장 큰 차이

 

PATCH

리소스 부분변경

지원이 안되는 서버가 있기도 하다. POST를 사용

  

DELETE

리소스제거

 

- HTTP 메서드의 속성

1) 안전

GET - 조회만 하므로 안전하다

(잦은 호출로 로그가 쌓여 장애가 난다는 고려하지 않음)

하지만 호출 시 변경이 일어나는 PUT, POST, DELETE등은 안전하지 않다.

 

2) 멱등

한 번 호출하든 100번 호출하든 결과가 똑같다.

POST - 중복이 발생할 수 있다. 멱등 x

GET, PUT, DELETE 등은 멱등이다. (다른 사용자의 POST로 인한 오류는 생각하지 않는다.)

자동 복구 메커니즘에 필요한 개념

잘못된 것 같을 때, 똑같은 요청을 다시 해도 되는가?

 

3) 캐시 가능

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

GET, HEAD 캐시 가능 POST, PATCH 가능하기는 하나 실무에서 사용하지 않음

캐시를 하려면 캐시 키를 고려해야 하는데 구현이 쉽지 않기 때문이다.