HTTP
0. 하이퍼텍스트
참조(하이퍼링크)를 통해 독자가 한 문서에서 다른 문서로 바로 접근할 수 있는 텍스트
1. HTTP란?
Hypertext transfer protocol으로 본래는 서버 클라이언트간에 하이퍼텍스트의 송/수신을 지원하는 프로토콜이다. 현재는 HTML 뿐만아니라 JSON, XML 등의 리소스들 을 가져오는것이 가능하다. https://developer.mozilla.org/ko/docs/Web/HTTP/Overview
2. REST 아키텍쳐 스타일
로이필링씨가 제안한 유연하고 확장 가능한 네트워크 아키텍처 스타일이다.
- 서버 클라이언트 모델: 컨텐츠의 조작, 조회는 서버가, 컨텐츠의 파싱은 클라이언트가 담당한다. (HTTP에서 웹브라우저와 서버 프로그램)
- 캐시 기능
- 계층형 아키텍처 지원: 프록시를 통한 방화벽, 캐시, 로드밸런서를 지원한다.
- stateless 모델: 전역 상태를 사용하지 않는다. 제공한 인자들을 활용해서만 요청을 진행한다.
- Uniform interface: 리소스에 대한 조작을 통일된 방식으로 수행한다. (URI, 회사마다의 API 규칙과 문서)
HTTP는 REST 아키텍처 스타일의 구현체라고 생각한다.
3. HTTP 객체의 구조
크게 start-line, header, body로 구성된다.
4. HTTP REQUEST
GET / http/1.1
Host: [developer.mozilla.org](https://developer.mozilla.org/)
Accept-Language: ko
start-line에는 METHOD, PATH, VERSION OF THE PROTOCOL, HEADERS 로 구성된다.
헤더에는 HTTP 메서드, 가져오려는 자원의 경로(프로토콜, 도메인, 포트를 제거한 나머지), HTTP 프로토콜의 버전. 서버에 대한 추가 정보를 전달하는 선택적 정보들이 들어있다.
마지막으로 body에 선택적으로 필요한 데이터를 동봉해 요청한다.
5. HTTP RESPONSE
HTTP/1.1 200 OK
Date: Sat, 09 Oct 2010 14:28:02 GMT
Server: Apache
Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT
ETag: "51142bc1-7449-479b075b2891b"
Accept-Ranges: bytes
Content-Length: 29769
Content-Type: text/html
start-line 에는 VERSION OF THE PROTOCOL, STATUS OF CODE, Status Message, 로 구성된다.
HEADERS 그리고 선택적으로 Content(Body)로 구성되어있다.
- HTTP 프로토콜의 버전.
- 요청의 성공 여부와, 그 이유를 나타내는 상태 코드, 상태 메시지.
- 그외 헤더들
6. HTTP METHOD
1. GET
GET 요청 방식은 URI(URL)가 가진 정보를 검색하기 위해 서버 측에 요청하는형태이다
2. HEAD
HEAD 요청 방식은 GET과 유사한 방식이나 웹 서버에서 헤더 정보 이외에는 어떤 데이터도 보내지 않는다. 웹 서버의 다운 여부 점검(Health Check)이나 웹 서버 정보(버전 등), 캐시 사전 검증을 위한 프리플라이트 요청을 위해 사용될 수 있다.
2. POST
POST 요청 방식은 요청 URI(URL)에 폼 입력을 처리하기 위해 구성한 서버 측 스크립트(ASP, PHP, JSP 등)
혹은 CGI 프로그램으로 구성되고 Form Action과 함께 전송되는데, 이때 헤더 정보에 포함되지 않고 데이터 부분에
요청 정보가 들어가게 된다.
3. PUT
POST와 유사한 전송 구조를 가지기 때문에 헤더 이외에 메시지(데이터)가 함께 전송된다.
원격지 서버에 지정한 콘텐츠를 저장하기 위해 사용되며 홈페이지 변조에 많이 악용되고 있다.
4. FETCH
PUT과 유사하게 요청된 자원을 수정(UPDATE)할 때 사용한다. PUT의 경우 자원 전체를 갱신하는 의미지만, PATCH는 해당자원의 일부를 교체하는 의미로 사용 https://stackoverflow.com/questions/28459418/rest-api-put-vs-patch-with-real-life-examples
5. DELETE
원격지 웹 서버에 파일을 삭제하기 위해 사용되며 PUT과는 반대 개념의 메소드이다
6. CONNECT
동적으로 터널 모드를 교환, 프록시 기능을 요청시 사용
8. OPTION
웹서버에서 지원되는 메소드의 종류를 확인할 경우 사용
HTTP 메소드와 멱등성
여러번 요청을 했을때 같은 결과가 나오는가? GET, PUT, DELETE는 멱등한 요청이다.
7. HTTP 응답코드
- 100 (서버의 현재 상태, 정보)
- 100 (information)
- 계속해서 요청을 보내도 된다!
- 요청을 보내기전에 미리 Content-length 헤더를 보내고 서버가 가용할수 있으면 판단한다.
- 101 (switching protocol)
- 프로토콜이 변경되었음을 클라이언트에 통지
- http → websocket
- 100 (information)
- 200 (정상응답)
- 300
- 301 (permenent): 웹 크롤러가 인식해 검색엔진 최적화에 활용할수 있다
- 302 (temporary): X
- 308 (not modified)
- 400
- 400: bad request
- 401
- 404
- 405
- 500
- 500: 어플리케이션 에러
- 503: 서버가 일시적으로 요청을 처리할수 없음
- 504: 타임아웃
8. 네트워크에서의 proxy?
오리진과 클라이언트에서 요청과 응답을 중계하는 계층
- 캐싱 (캐시는 공개 또는 비공개가 될 수 있습니다 (예: 브라우저 캐시))
- 필터링 (바이러스 백신 스캔, 유해 컨텐츠 차단(자녀 보호) 기능)
- 로드 밸런싱 (여러 서버들이 서로 다른 요청을 처리하도록 허용)
- 인증 (다양한 리소스에 대한 접근 제어)
- 로깅 (이력 정보를 저장)
9. HTTP에서의 캐시
- 클라이언트 캐시: 웹브라우저에 관리하는 캐시
- 프록시 캐시: 오리진과 클라이언트 중간에 있는 계층의 캐시
- 웹서버 캐시
10. 캐시 관련 HEADERS
- Cache-Control (캐시 지침 설정)
- max-age: 리소스를 캐시에 저장할 최대 시간(초)
- no-cache: 캐시된 리소스를 사용하기 전에 항상 원본 서버에 검증 요청
- no-store: 리소스를 캐시하지 않는다.
- must-revalidate: 캐시 만료시 반드시 확인요청을 한다. origin 서버의 검증을 반드시 거쳐야 하며 불가능시 오류 발생.
- public: 리소스를 공유 캐시에 저장하도록 허용 (프록시에 저장 가능)
- private: 리소스를 개인적인 캐시에만 저장하도록 한다 (프록시에 저장 불가능)
- Expires
- 캐시 만료 날짜와 시간
- ETag
- ETag 헤더는 리소스의 고유한 식별자.
- 캐시 유효성 검사를 위해 서버에 요청할 때 사용.
- If-None-Match:
- If-None-Match 헤더는 이전에 저장된 리소스의 ETag 값을 포함한다. 서버에 요청 시 이전에 저장된 리소스의 ETag 값과 비교하여 변경 여부를 확인하고, 변경이 없다면 304 Not Modified 응답을 받아 캐시를 재사용할 수 있다.
- Last-Modified:
- Last-Modified 헤더는 리소스가 마지막으로 수정된 날짜와 시간을 나타낸다. 캐시 유효성 검사를 위해 서버에 요청할 때 사용된다.
- If-Modified-Since:
- If-Modified-Since 헤더는 이전에 저장된 리소스의 Last-Modified 값을 포함한다. 서버에 요청 시 이전에 저장된 리소스의 수정 날짜와 비교하여 변경 여부를 확인하고, 변경이 없다면 304 Not Modified 응답을 받아 캐시를 재사용할 수 있다.
- Pragma : no-cache
- HTTP 1.0 하위호환 ETag와 If-None-Match, Last-Modified와 If-Modified-Since는 한쌍이다.
만약 서버에 도달한 메시지가 Last-Modified, If-Modified-Since 모두 가지고 있다면 서버는 두 조건이 동시에 충족되어야 하므로, ETag 값과 Last-Modified 값 모두가 이전에 클라이언트에 응답으로 보낸 값과 일치하면 304 Not Modified 응답을 반환하여 클라이언트가 캐시를 재사용하도록 한다.
10. 요청 Header
Cookie: 서버의 Set-Cookie로 인해 설정된 쿠키 정보
Referer: 클라이언트(웹 브라우저)가 현재 요청한 리소스를 어떤 웹 페이지에서 링크를 클릭하거나 요청한 것인지를 나타내는 HTTP 헤더
Authorization: 토큰/세션 정보
Origin: 요청이 시작된 주소, CORS와 관련되어있음
11 Restful API
REST 아키텍처의 유니폼 인터페이스를 지키도록 노력한 API
유니폼 인터페이스는 다음과 같은 구성요소들이 있다.
리소스 식별과 조작: 유니폼 인터페이스는 모든 리소스를 고유하게 식별하는 URI(Uniform Resource Identifier)를 사용하여 표현합니다. 각 리소스는 URI를 통해 접근하고 조작할 수 있어야 한다. 유니폼 인터페이스는 리소스를 조작하기 위해 표준 HTTP 메서드(예: GET, POST, PUT, DELETE)를 사용합니다. 이러한 메서드는 리소스에 대한 특정한 작업을 수행하는 데 사용됩니다.
self-descriptive: 모든 요청과 응답은 리소스에 대한 충분한 정보를 포함하여 자기서술적(self-descriptive)이어야 한다. 즉, 요청이나 응답의 내용만으로도 어떤 동작이 필요한지 이해할 수 있어야 한다. 이를 위해 HTTP 헤더를 적절히 사용하고, 표준 미디어 타입 (예: JSON, XML)을 이용하여 데이터를 표현한다.
hypermedia 사용: 리소스와 관련된 하이퍼링크를 통해 클라이언트가 리소스와 상호작용할 수 있도록 유니폼 인터페이스를 구성한다. 이를 통해 클라이언트는 상태 전이를 따라서 원하는 리소스로 이동할 수 있다. 주로 하이퍼미디어 포맷인 HATEOAS(Hypermedia as the Engine of Application State)를 사용하여 구현한다.
대표적으로 동사는 HTTP메소드, 명사는 url, 하이퍼미디어를 첨부하는 방식으로 허드슨모델이라고 한다.
Leave a comment