HTTP(HyperText Transfer Protocol)
데이터를 주고받기 위한 통신 규약
request / response
HTTP 특징
인터넷 상에서 불특정 다수의 통신 환경을 기반으로 설계. 만약 서버에서 다수의 클라이언트와 상태나 연결을 계속 유지해야할 경우, 많은 서버의 리소스가 필요하다.
- 클라이언트와 서버 구조
클라이언트는 UI에 중점 / 서버는 데이터, 비즈니스 로직 담당 - 무상태 (Stateless)
- 서버는 클라이언트의 상태를 보존하지 않음
- Scale out, 수평 확장성이 높음
- 갑자기 요청량이 증가하여도 서버를 증설하기 쉬움
- 무상태로 설계할 수 없는 경우가 있음
- 로그인 구현? → Cookie, Session, Token
- 비연결 (Connetionless)
- HTTP는 연결을 유지하지 않는 모델
- 서버 자원을 효율적으로 사용할 수 있으나,
- 추가 요청시 연결(3 way handshake)를 새로 해야함 -> 요청에 대한 응답 시간 증가
- 웹사이트의 정적 자원 다시 다운로드해야함 -> 임시저장 사용 (캐시, 브라우저 캐싱)
- 현재는 HTTP 지속연결(Persistent Connection)로 문제 해결
- 하나의 요청에 필요한 요청들이 모두 응답될 때까지 연결 유지
- 연결을 한번만 맺고 끊어, Connectionless 방식보다 연결 횟수 적음 -> 그만큼 빠름
HTTP Message 구조
request message vs response message
request
- Start Line
- HTTP Method: GET, POST, PUT, PATCH, DELETE 등
- path; 절대 경로, Query String(Query Parameter) 값도 포함
- HTTP version
- Header
Host: spartacodingclub.kr
- field-name: OWS field-value OWS (OWS : 띄어쓰기 허용) 구조
- field-name 은 대소문자 구분 =없음
- 임의의 Header를 추가 가능 (단, 서버가 값을 알고 있어야 함)
- 요청의 추가 정보
- ex) Message Body 내용, 크기, 인증, 브라우저 정보, 서버 정보 등
- Empty Line
- 공백 한 줄, 필수 값
- Message Body
- 실제 전송하는 데이터가 담겨 있는 부분
- HTML, 이미지, JSON 등 byte로 표현되는 모든 데이터 전송 가능.
- 요청 시 GET의 경우 Message Body가 지원되지 않는 경우가 많아 권장 X
response
- Start Line
- HTTP version
- Status Code (200, ...)
- Status Text: 코드와 함께 전달될 메세지
- Header
- response에서 사용되는 Header 값
- Empty Line
- 공백 한 줄, 필수 값
- Message Body
- 실제 전송하는 데이터가 담겨 있는 부분
- 만약 전송할 데이터가 없다면, 공백으로 존재
HTTP Method
POST
: CREATE, Message Body를 통해 요청 데이터 전달
GET
: RETRIEVE, 서버에 추가적 데이터 전송이 필요할 시, Query String(Query parameter) 사용
PUT
: 덮어쓰기, 기존 리소스가 존재하면 덮어 쓰고, 없으면 생성됨
PATCH
: UPDATE, 리소스 부분 수정
DELETE
: DELETE
기타
- HEAD: 상태줄&헤더만 반환
- OPTION: 대상 리소스에 대한 통신 가능한 method 설명
- CONNECT: 대상 지원으로 식별되는 서버에 대한 터널 설정
- TRACE: 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트 수행
HTTP Method 속성
- 안전성 (safe)
GET(안전, 데이터 변환 X) / POST, DELETE, PUT, PATCH (안전 X) - 멱등성(idempotent)
몇 번 호출해도 결과가 동일, 요청이 실패할 시 재시도 해도 무관
POST; 멱등성 보장 X - 캐시가능성 (Cacheable)
재사용을 위해 요청에 대한 응답을 저장할 수 있는가?
GET, HEAD, POST method는 cacheable 하지만, 일반적으로 GET, HEAD 정도만 캐시로 사용함
HTTP 상태 코드
1XX (정보)
요청 수신 후 처리중인 상태
2XX (성공)
정상 처리 완료된 상태
- 200 (ok), 201 (created), 202 (accepted), 204 (No content)
3XX (리다이렉션)
요청을 완료하려면 추가 행동이 필요한 상태
3XX + Location HTTP Header => Location으로 리다이렉트
- 영구 리다이렉션 : URI이 영구적으로 변경된 경우, 기존 URI을 사용하지 않음
- 301 (moved permanently), 308 (Permanent redirect) - 일시 리다이렉션 : URI가 일시적으로 변경
- ex)) PRG pattern (Post → Redirect → Get)
- 302 (Found), 303 (See Other)(request -> GET), 307 (Temporary Redirect) - 기타 : 캐시를 활용할 것인지에 대한 여부
- 304 (Not modified)
4XX (클라이언트 에러)
클라이언트측 에러, 잘못된 문법등으로 서버가 요청을 수행할 수 없음
- 400 (Bad Request), 401 (Unauthorized), 403 (Forbidden) (authorization 문제) , 404 (Not Found)
5XX (서버 에러)
요청은 정상이나 서버가 처리 불가함, 재시도에서 성공할 수 있음
- 500 (Internet Server Error), 503 (Service Unavailable)
HTTP API 설계
HTTP Header
클라이언트와 서버가 요청 또는 응답으로 부가적인 정보 (Message Body 내용, 크기, 인증, 브라우저 정보, 서버 정보 등)를 전송할 수 있게 함
구조
field-name: OWS field-valueOWS OWS 띄어쓰기 허용)field-name은 대소문자 구분 X- HTTP 전송에 필요한 모든 부가정보를 표현할 수 있음
- 임의의 Header를 추가할 수 있다. 단, 서버가 값을 알고있어야 함
- 텍스트 (plain text)로 구성
- 각각의 헤더는 하나의 줄로 구분됨
HTTP Header 모음집
표현 헤더(Representation)
: 데이터의 특정 형식
| 종류 | 설명 | 예시 | |
|---|---|---|---|
| Content-Type | 형식 | 전송할 데이터의 미디어 타입 및 문자 인코딩 | text/html; charset=utf-8application/json |
| Content-Encoding | 압축방식 | 데이터의 압축 방식 데이터를 압축한 후 이 헤더를 추가하면, 수신 측에서 해당 정보로 압축을 해제함 | gzipidentity (압축하지 않음) |
| Content-Language | 언어 | 데이터의 언어 | ko (한국어)en (영어) |
| Content-Length | 길이 | 데이터의 길이의 바이트 단위. 실제로는 표현 헤더가 아닌 페이로드 헤더 | 숫자 값 (예: 1024) |
컨텐츠 협상(Content Negotiation)
클라이언트가 선호하는 표현을 요청, 요청시에만 사용되는 Header, 우선 순위가 존재
- 우선순위 : q (
Quality values), 0 ~ 1의 값, 높을 수록 우선순위가 높음, 1일 경우 생략 가능
- q가 생략되었을 경우 선언된 순서대로 우선순위를 가짐- 구체적으로 선언될수록 우선순위가 높음
- 종류 : Accept(선호하는 미디어 타입), Accept-Charset (선호하는 문자 인코딩), Accept-Encoding (선호하는 압축 인코딩), Accept-Language (선호하는 언어)
일반 정보
단순한 정보
- Form: 클라이언트 이메일 정보
- Refer: 현재 요청된 페이지의 이전 웹 페이지 주소
- User-Agent: 클라이어늩 애플리케이션 정보 (어떤 환경에서 주로 접속하는지, 장애가 발생하는지)
- Server: 요청을 처리하는 ORIGIN 서버의 Software 정보
- Date: HTTP 요청 발생 날짜+시간
특별 정보
- Host: 요청한 돕메인 정보, 요청시 필수
- Location: 생성된 리소스 URI, 리다이렉트 주소
- Allow: 허용 가능한 HTTP Method, 405 (Method Not Allowed)와 함께 응답
- Retry-After: 다음 요청까지 대기해야하는 시간, 503 (Serverice Unavailable)과 함께 응답
인증
- Authorization: 클라이언트 인증 정보
- WWW-Authenticate: 리소스에 필요한 인증 방법, 401 (Unauthorized) 응답과 함께 사용
Cookie
HTTP는 Stateless 특성을 가지고 있어서 상태를 매번 보내주어야 한다.
사용자 세션 관리, 광고 정보 트래킹에 많이 사용됨
- Set-Cookie: 서버에서 응답시 클라이언트로 Cookie값 전달
- Cookie: 클라이언트가 서버에서 받은 쿠키를 Cookie 헤더를 통해 전송
- Secure: 해당 헤더가 적용되면 https인 경우에만 Cookie 전송
- HttpOnly: http 전송에만 사용, 자바스크립트에서 쿠키 접근하지 못하도록 함
- SameSite: 쿠키에 설정된 도메인이 같은 경우에만 쿠키 전송
Cache
- Cache-Control: 응답 시 사용
Cache-Control: max-age(유효시간(초)), 유효 시간 이후에 서버를 통해 데이터를 응답받고 캐시 재발급Cache-Control: no-cache, 캐시 가능한 데이터지만, 서버에 검증 필요Cache-Control: no-store, 보안에 민감한 데이터, 캐시 하지 않음
- if-modified-since: 캐시로 저장된 데이터 최종 수정일, 요청시 사용
- Last-Modified: 데이터가 마지막으로 수정된 시간
- ETag: 캐시용 데이터에 날짜, 시간이 아닌 이름 지정
Restful API
REST를 잘 준수하는 API로 HTTP 프로토콜을 사용하여 클라이언트와 서버 간의 통신을 통해 자원
(Resource)을 관리한다. 자원은 고유한 URI로 식별되며, HTTP 메서드(GET, POST, PUT, DELETE 등)를 통해 다양한 작업을 수행하며 요청과 응답은 일반적으로 JSON 또는 XML 형식으로 이루어진다.
REST (Representational State Transfer)란?
자원(Resource)을 이름(Name)으로 구분하여 해당 자원의 상태(정보)를 주고받는 것
URI를 통해 자원(Resource)을 명시하고, HTTP Method(POST, GET, PUT, DELETE,PATCH 등)를 통
해 해당 자원에 대한 CRUD Operation을 적용하는 것
- 리소스는 명사를 사용해야 한다.
- 단수가 아닌 복수 형태를 사용해야 한다.
- 만약, REST만으로 해결하기 어려운 경우라면 동사를 허용한다.
- 자원의 계층 관계를 슬래시(/)로 표현한다.
- 마지막 문자에는 슬래시(/)가 있으면 안된다.
- 언더바(_)가 아닌 하이픈(-)을 사용해야 한다.
- 소문자를 사용해야 한다.
- URI에 파일 확장자를 포함하면 안된다.
- CRUD 함수명은 사용하지 않고, HTTP Method를 활용해야 한다.
- 정렬, 필터링, 페이징은 신규 API를 만드는것이 아닌 Query Parameter를 사용해야 한다.
