HTTP(HyperText Transfer Protocol)
HTML, 이미지, 영상, JSON 등 거의 모든 형태의 데이터를 전송할 수 있는 프로토콜로, 클라이언트와 서버의 요청(Request),응답(Response) 구조를 가진다. 서버가 클라이언트의 상태를 보존하지 않는 무상태(Stateless) 설계로 현재 서버에 문제가 생길 경우 다른 서버가 응답이 가능하여 서버 확장성에 큰 장점이 있으며, 로그인 같이 상태 유지가 필요한 경우 브라우저 쿠키, 서버 세션 등으로 상태를 유지할 수 있다.
HTTP 메시지 구조
1. 시작 라인
- 요청 시 - HTTP 메서드, 경로, 쿼리 파라미터, HTTP 버전
- (GET /search?page=5 HTTP/1.1)
- 응답 시 - HTTP 버전, 상태 코드, 상태 설명
- (HTTP/1.1 200 OK)
2. 헤더
- HTTP 전송에 필요한 모든 부가 정보
- 요청 시 - Host: www.google.com
- 응답 시 - Content-Type, charset, Content-Length
- Content-Type : 미디어 타입, 문자 인코딩(text/html; charset=utf-8, application/json)
- Content-Language : 표현 데이터의 자연 언어를 표현 (ko, en ..)
- Accept : 협상 헤더, 클라이언트가 선호하는 표현 요청 (Accept, Accept-Charset, Accept-Language ..)
- (Content-Type:text/html;charset=UTF-8 Content-Length: 3423)
3. 공백 라인
- 헤더와 메시지 바디 사이에 엔터 공백 (CRLF)
4. 메시지 바디
- 실제 전송할 데이터
- HTML 문서, 이미지, 영상 ,JSON 등 byte로 표현할 수 있는 모든 데이터 전송 가능
HTTP API
URI 설계에서 가장 중요한 것은 리소스 식별로 행위는 배제하고 리소스(member) 자체를 URL에 매핑한다.
계층 구조를 활용하여 상위를 컬렉션으로 보고 복수 단어로 사용하는 것이 좋다. (특정 회원 : members/id)
URL 설계의 핵심은 리소스와 행위를 분리하고 리소스만 식별하는 것인데 행위는 HTTP 메서드로 구분한다.
문서(document)
- 단일 개념
- ex. members/1
컬렉션(collection)
- 서버가 관리하는 리소스 디렉토리
- 서버가 리소스의 URL를 샌성하고 관리
- ex. /members
스토어(store)
- 클라이언트가 관리하는 리소스 저장소
- 클라이언트가 리소스의 URL를 알고 관리
- ex. /files
컨트롤러(controller)
- 문서, 컬렉션, 스토어로 해결하기 어려운 경우 추가 프로세스
- 동사를 직접 사용
- ex. /membmers/3/delete
HTTP 메서드
[정리]
GET
- 리소스 조회
- 서버에 전달할 데이터는 쿼리를 통해 전달
- 요청에 메시지 바디가 없다.
- 멱등성(몇번을 해도 같은 결과)
POST
- 요청 데이터 처리
- 메시지 바디를 통해 서버로 데이터 전달
- HTML FORM에 입력한 정보를 전송
- 새로운 리소스를 생성하거나 프로세스의 상태가 변경되는 경우, 다른 메서드로 처리하기 애매한 경우 주로 사용
- 같은 요청 반복 시 중복 처리 위험 (멱등성 X)
PUT
- 리소스 전체 대체(부분 변경 X), 해당 리소스가 없으면 생성 (덮어쓰기)
- 클라이언트가 리소스 위치를 알고 URI 지정(POST와 차이점)
PATCH
- 리소스 부분 변경
DELETE
- 리소스 삭제
- 요청에 메시지 바디가 없다.
HTML FORM 데이터 전송
- GET, POST만 지원 (대부분 POST 전송)
- Content-Type : application/x-www-form-urlencoded (form 데이터를 메시지 바디를 통해 key&value 형식 전송)
- 전송 데이터를 url encoding 처리 (abc김 -> abc%EA%B9%80)
- Content-Type: multipart/form-data (파일 업로드 같은 바이너리 데이터 전송, 다른 종류의 파일과 form 내용 전송 가능)
HTTP API 데이터 전송
- 서버 <-> 서버 : 백엔드 시스템 통신
- 앱 클아이언트(아이폰, 안드로이드)
- 자바스크립트, React, VueJs 같은 웹 클라이언트와 통신
- Content-Type: application/json 으로 대부분 사용
HTTP 상태 코드
1xx : 요청이 수신되어 처리중
2xx : 요청 정상 처리 (200 OK, 201 Created, 202 Accepted, 204 No Content)
3xx : 요청을 완료하려면 추가 행동이 필요 (응답 결과에 Location 헤더가 있으면 Location 위치로 리다이렉트)
4xx : 클라이언트 오류, 문법 에러 등으로 서버가 요청을 수행할 수 없는 경우 (400 Bad Request, 404 Not Found)
5xx : 서버 오류, 서버가 정상 요청을 처리하지 못하는 경우 (500 Internal Server Error)
클라이언트는 인식할 수 없는 상태코드를 응답 시 상위 상태코드로 해석 (299 -> 2xx, 451 -> 4xx)
쿠키
- HTTP의 무상태성(Stateless)을 보완하기 위해 상태 유지를 위해 사용
- Set-Cookie : 서버에서 클라이언트로 쿠키 전달 (응답시 전달)
- Cookie : 클라이언트가 서버에서 받은 쿠키를 저장, HTTP 요청시 서버로 전달 (요청시 전달)
- 쿠키 정보는 항상 서버에 전송되기 때문에 트래픽 유발 위험, 최소한의 정보만 사용
- 보안에 취약
- 만료일(expires) 또는 시간(max-age)으로 생명 주기, 시간을 0 또는 음수로 지정 시 쿠키 삭제
- 세션 쿠키 : 만료 날짜 생략 시 브라우저 종료시 까지만 유지
- 영속 쿠키 : 만료 날짜 입력하면 해당 날짜까지 유지
- Secure : https인 경우에만 전송
- HttpOnly : XSS 공격 방지, HTTP 전송에만 사용
- SameSite : 요청 도메인과 쿠키에 설정된 도메인이 같은 경우에만 쿠키 전송
캐시
- 응답 결과를 브라우저 캐시에 저장하고 같은 데이터 조회 시 캐시에서 조회
- 네트워크 사용량이 줄어들고, 브라우저 로딩 속도가 빨라진다.
- 응답 캐시 지시어 cache-control: max-age(유효 시간), no-cache(서버 검증 후 사용), no-store(저장x)
- 캐시 시간이 만료된 경우
- 클라이언트는 서버가 보낸 응답 헤더 정보로 캐시에 저장되어 있는 데이터를 재활용하여 갱신 가능
- 변경이 있으면 서버를 통해 다시 데이터를 조회하고, 캐시 시간을 갱신
- Last-Modified, ETag : 캐시 데이터와 서버 데이터를 비교하는 검증 헤더 (응답!)
- ETag : 캐시 데이터에 고유한 버전 이름을 달아두고 데이터가 변경되면 ETag를 바꾸어서 변경
- 요청 헤더 : if-Modified-Since(Last-Modified), if-None-Match(ETag)
- 서버의 데이터가 갱신되지 않았으면 304 Not Modified + 헤더 정보만 응답(바디 x)
* 자세한 것은 찾아보고 사용하는 것이 좋음
[참고] 인프런 김영한님 강의를 공부한 내용입니다.