<학습 목표>
- 프론트엔드와 백엔드의 역할을 이해한다
- HTTP 메시지의 구조를 이해한다
- Request와 Response 메시지의 역할을 이해한다
- HTTP 상태코드의 역할을 이해한다
- HTTP 헤더의 역할을 이해한다
- 웹의 요청 흐름을 이해한다
- State와 Stateless의 뜻을 이해한다
- Restful한 API 설계를 할 수 있다
<HTTP>
HyperText transfer Protocol
- 원래는 HTML 전송용으로 나왔으나 현재는 모든 형태를 전송함
- 이미지, 음성, 영상, 파일, JSON, XML 등등
- 웹의 요청 흐름
- 클라이언트가 서버로 Request를 보내면 서버가 클라이언트한테 Response를 보내는 구조
- 무상태 프로토콜(stateless)
- 서버가 클라이언트 상태를 보존하지 않음
- 무상태는 응답 서버를 쉽게 바꿀 수 있음
- 비연결성
- 요청 시마다 연결을 유지하면 클라이언트가 연결을 하면 할수록 서버가 터짐
- HTTP는 기본적으로 연결을 유지하지 않음
- 1시간 동안 수천 명이 써도 실제 동시 처리하는 요청은 몇십 개도 안 됨
- 서버 자원을 효율적으로 쓸 수 있음
- HTTP 메시지의 구조
- HTTP 상태코드
1xx
요청이 수신되어 처리 중
- 거의 사용되지 않음
2xx
요청 정상 처리
- 200 OK
- 201 Created
- Header에 Location을 추가해서 새로운 리소스의 URI를 알려줄 수 있음
- 202 Accepted
- 요청은 접수했음
- 204 No Content
- save 버튼 눌러서 저장만 하고 화면 변화가 필요없을 때에
- 보통 그냥 200이랑 201만 씀. 개발팀끼리 협의.
3xx
추가 행동 필요
- 웹브라우저는 3xx의 헤더에 Location이 있으면 자동으로 리다이렉트 함
- 영구 리다이렉트 : 영구 이동. 메소드와 바디가 바뀌는 301과 안 바뀌는 308이 있음
- 일시 리다이렉트 : 일시적 변경. 주문 완료 후 주문내역으로 이동
- 302 : 리다이렉트 시 메소드는 GET으로. 본문은 제거.
- 307 : 리다이렉트 시 메소드와 본문 유지
- PRG(Post/Redirect/Get)
- Post 주문 후 새로고침 시 중복 주문이 가능함
- 주문 완료 시 302를 줘서 리다이렉트 시키면 새로고침 해도 결과 화면만 다시 요청함
4xx
클라이언트 에러
- 잘못된 문법. 오류의 원인이 클라이언트에 있음.
- 400 : 요청 내용을 다시 검토해야 함. API 스펙이 맞는지를 확실히 해야 함.
- 401 : 인증이 안 됨
- 403 : 권한이 없음
- 인증 vs 권한 : 인증은 로그인이 안 됨. 권한은 내가 운영자가 아님. Authentication vs Authorization
- 오류는 Unauthorized로 쓰임
- 404 : 리소스가 없음 또는 숨기고 있음
5xx
서버 에러
- 복구 후 재시도 시 성공 가능함
- 500 : 서버 내부 문제
- 503 : 서버가 일시 과부하
- HTTP의 다양한 헤더들
- field-name(key)는 대소문자 구분이 없음
- content-type = Content-Type
- HTTP 전송에 필요한 모든 부가정보
- 메시지 바디의 내용
- 메시지 바디의 크기
- 압축
- 인증
- 요청 클라이언트
- 캐시 관리
- 표준 헤더가 너무 많고 필요 시 임의의 헤더도 추가 가능함
- 헤더에는 바디의 데이터를 해석할 수 있는 정보를 제공함
표현
리소스에 대한 정보. html vs xml vs json
- Content-Type : 형식
- text/html;charset=utf-8
- application/json
- image/png
- Content-Encoding : 압축방식. 압축해서 보내준 경우.
- gzip
- deflate
- identity : 압축 안 했다는 뜻
- Content-Language : 영어, 한국어 등
- ko
- en
- en-US
- Content-Length : 길이
- 바이트 단위
- Transfer-Encoding 사용 시 Content Length는 사용하면 안 됨
컨텐트 협상(Content negotiation)
요청 시에만 사용됨
- Accept : 클라이언트가 선호하는 미디어 타입 전달.
- 구체적인 것이 우선됨
- text/plain;format=flowed
- text/plain
- text/*
- 구체적인 것이 우선됨
- Accept-Charset : 클라이언트가 선호하는 문자 인코딩
- Accept-Encoding : 클라이언트가 선호하는 압축 인코딩
- Accept-Language : 클라이언트가 선호하는 자연 언어
- 서버에서 다중 언어를 지원
- 한국어 브라우저를 쓰면 한국어를 선호한다는 것을 알려줌
- 서버에서 한국어로 보내줌
- 여러가지 언어에 대한 우선순위가 필요한 경우 quality values(q)를 사용함
- 1이 가장 높고 0이 가장 낮음. 생략 시 1
- accept-language: en;q=0.9,ko;q=0.8
전송 방식
- 단순 전송
- Content-Length
- 압축 전송
- gzip 같은 걸로 서버에서 압축 시 절반 정도로 줄어듦
- Content-Encoding : gzip 으로 알려줘야 클라이언트에서 알고 풂
- 분할 전송
- Transfer-Encoding : chunked -> content length를 보내면 안 됨
- 용량이 큰 걸 분할해서 전송함
- 범위 전송
- Range 명시로 어디서 어디까지 왔는지
일반 정보
- referer
- 어디에서 왔니?
- 유입 경로 분석용
- user-agent
- 어느 브라우저니?
- 특정 브라우저에서만 오류가 생기는 것을 파악하기 좋음
- 사용자들이 어느 브라우저를 사용하는지 알 수 있음
- server
- 요청을 처리하는 서버의 소프트웨어 정보
특별 정보
- Host
- 요청한 호스트 정보(도메인)
- 필수값
- 하나의 서버에 여러 IP가 있을 수 있기 때문에 필요함
- 초창기에 많은 문제가 있어서 Host는 필수로 들어가게 됨
- Allow
- 허용 가능한 메서드
- 405 Response를 줄 때 응답에 포함함
- Retry-After
- 날짜 혹은 초단위 표기로 다시 요청을 하라고 하나 사용하기는 쉽지 않음
인증
- Authorization
- 클라이언트의 인증 정보를 서버에 전달
- 인증 방식에 따라 들어가는 값은 상이함
- WWW-Authenticate
- 리소스 접근 시 필요한 인증 방법 정의
- Response 시 401 Unauthorized와 함께 사용
- 어떻게 인증 정보를 만들지에 대한 정보
쿠키
- Set-Cookie
- Response 시 서버에서 클라이언트로 쿠키 전달
- 만료기간 / 경로 / 도메인을 설정해 줄 수 있음
- 사용처 : 로그인 세션 관리(쿠키-세션 방식), 광고 정보 트래킹
- 쿠키는 항상 서버에 전송되다 보니 트래픽이 추가 유발됨 -> 최소한의 정보만 쓰자
- 서버에 전송이 필요없고 웹브라우저에 저장만 하고 싶으면 localStorage를 쓰면 됨
- 보안에 민감한 주민번호, 신용카드 번호 등은 저장하지 않음
- 만료일자를 생략하면 브라우저 종료 시 삭제
- 만료일(expires)이나 시간(max age)을 지정할 수 있음
- 경로 지정으로 원하는 도메인에만 쿠키를 보냄
- Cookie
- 클라이언트가 서버에서 받은 쿠키를 저장
- 요청 시 서버로 전달
캐시(Cache)
- Cache-control : max-age
- 캐시 유효 기간
- Cache-control : no-cache
- 서버에 검증하고 사용
- Cache-control : no-store
- 민감한 정보로 최대한 빨리 삭제