HTTP(Hyper Text Protocol)

1. HTTP(Hyper Text Protocol)

HTML 문서와 같은 리소스들을 가져올 수 있도록 해주는 프로토콜

HTTP 개요 - HTTP | MDN

(1): HTTP 메시지

요청(request) : 클라이언트가 서버로 전달해서 서버의 액션이 일어나게끔 하는 메시지

응답(response) : 요청에 대한 서버의 답변

(2): HTTP 요청

HTTP 메서드
주로 URL, 또는 프로토콜, 포트, 도메인의 절대 경로
HTTP 버전

1) Header

General Header(공통 헤더) : 공통 헤더는 요청 및 응답의 메시지 모두에서 사용되지만 컨텐츠에는 적용되지 않는 헤더
Request Header(요청 헤더) : HTTP 요청에서 사용되지만 메시지의 컨텐츠와 관련이 없는 HTTP 헤더
Response Header(응답 헤더) : 위치 또는 서버 자체에 대한 정보(이름, 버전)과 같이 응답에 대한 부가적인 정보를 갖는 헤더
Entity Header(엔티티 헤더) : 컨텐츠 길이나 MIME 타입과 같이 Entity Body에 대한 자세한 정보를 포함하는 헤더

(1) General Header 주요 속성

Date : (day-name), (day) (month) (year) (hour):(minute):(econd) GMT
Connection : close, Keep-Alive ⇒ close는 메세지 교환 후 TCP 연결 종료 , Keep-Alive는 메세지 교환 후 TCP 연결 유지

(2) Request Header 주요 속성

Host : 요청하는 자의 호스트명, 포트 번호
User-Agent : 요청자의 소프트웨어 정보
Accept : 원하는 미디어의 타입 및 우선순위

Accept: application/json, text/plain, /
- json > text > all type 순으로 받는다.
Accept-Language: en-US,en;q=0.5
- 언어는 en이다. q는 가중치.
Accept-Encoding: gzip, deflate, br
- gzip, deflate, br(Brotli) 등등의 압축 포맷을 받는다
cookie : 서버에 의해서 이전에 저장된 쿠키를 포함시키는 속성
Referer : 현재 요청을 보낸 페이지의 절대 혹은 부분 주소를 포함

(3) Response Header 주요 속성

Server : 서버 소프트웨어의 정보
content-encoding : 응답하는 내용의 인코딩 포맷
content-type : 응답하는 내용의 타입과 문자 포맷
cache-control : 캐시 관리에 대한 정보
date : 응답 메세지가 생성된 시간
vary : 캐시된 응답을 향후의 응답에 사용할 기준
Set-Cookie : 서버에서 사용자에게 세션 쿠키 정보
Age : max-age내에서 캐시가 얼마나 지났는지의 초 단위

(4) Entity header 주요 속성

Content-Type : 본문의 미디어 타입을 나타내기위해 사용
Content-Encoding : 미디어 타입을 압축하기 위해서 사용
Content-Length : 본문의 길이
Content-Language : 본문이 대상으로 하는 언어
Content-Location : 컨텐츠에 접근할 수 있는 위치
Allow : 리소스가 지원하는 메소드의 집합

2) HTTP Method 종류

(1) 주요 메소드

GET : 리소스 조회
POST: 요청 데이터 처리, 주로 등록에 사용
PUT : 리소스를 대체(덮어쓰기), 해당 리소스가 없으면 생성
PATCH : 리소스 부분 변경 (PUT이 전체 변경, PATCH는 일부 변경)
DELETE : 리소스 삭제

(2) 기타 메소드

HEAD : GET과 동일하지만 메시지 부분(body 부분)을 제외하고, 상태 줄과 헤더만 반환
OPTIONS : 대상 리소스에 대한 통신 가능 옵션(메서드)을 설명(주로 CORS에서 사용)
CONNECT : 대상 자원으로 식별되는 서버에 대한 터널을 설정
TRACE : 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행

GET METHOD 활용

예) GET/members/100?username=inpa&height=200

조회할 때 POST도 사용할 수 있지만, GET 메서드는 캐싱이 가능하기에 GET을 사용하는 것이 유리하다.

정적 데이터 조회

이미지, 정적 텍스트 문서 GET
쿼리 파라미터 없이 리소스 경로로 단순하게 조회 가능

서버에 전달하고 싶은 데이터는 쿼리스트링를 통해서 전달

클라이언트에서 /members/100 으로 100번 멤버를 조회해서 정보를 달라고 GET 요청
서버에서는 요청 메세지를 분석해 내부의 유저정보를 조회한 뒤 결과 Response를 만든다.
서버에서 클라이어트로 응답을 해준다. 그러면 클라이언트에서 정상적으로 받으면 200 OK status를 가지며, 회원정보를 얻게 된다.

동적 데이터 조회

주로 검색, 게시판 목록에서 검색어로 이용
쿼리 파라미터 사용해서 데이터를 전달
쿼리 파라미터는 key1=value1&key2=value2 구조로 되어 있음

요청 URL 뒤에 ?q=hello&hl=ko 쿼리 파라미터를 줘서 상세한 조회 데이터를 얻는다

POST METHOD 활용

전달한 데이터 처리/생성 요청 메서드 (Create)
메시지 바디(body)를 통해 서버로 요청 데이터 전달하면 서버는 요청 데이터를 처리하여 업데이트
전달된 데이터로 주로 신규 리소스 등록, 프로세스 처리에 사용
만일 데이터를 GET 하는데 있어, JSON으로 조회 데이터를 넘겨야 하는 애매한 경우 POST를 사용

클라이언트는 body에 등록할 회원 정보를 JSON 형태로 만들어 담고 서버로 전송한다.
서버에서는 받은 메세지를 분석해 로직 대로 처리 한다. 예를 들어 데이터베이스에 등록하고 신규 아이디를 생성
신규회원에 대한 데이터를 바디에 담아서 클라이언트로 응답

PUT METHOD 활용

만일 요청 메세지에 리소스가 있으면 덮어쓰고, 없으면 새로 생성
데이터를 대체해야 하니, 클라이언트가 리소스의 구체적인 전체 경로를 지정해 보내주어야 한다.

PUT 요청에 리소스가 있는 경우

100번 유저의 리소스를 교체하겠다는 요청을 보낸다.
기존에 데이터가 있었다면 완전히 대체
서버에서 클라이어트로 응답을 해준다. 그러면 클라이언트에서 정상적으로 받으면 200 OK status를 가지며, 회원정보를 얻게 된다.

PUT 요청에 리소스가 없는 경우

100번 유저의 리소스를 교체하겠다는 요청을 보낸다.
기존에 데이터가 없다면 POST 와 같이 신규로 생성

PUT 요청에 일부 리소스만 변경하길 원할 경우

age만 50으로 변경하려고 해당 데이터를 PUT으로 전달한다.
하지만 기존 데이터가 완전히 대체되어 이름 데이터가 삭제된다. (이때는 PATCH 메소드를 이용해야 한다)

PATCH METHOD 활용

만일 PATCH를 지원하지 않는 서버에서는 대신에 POST를 사용할 수 있다.

age만 50으로 변경하려고 해당 데이터를 PATCH로 전달한다.
PUT과는 다르게 회원 정보에서 age만 변경된다.

DELETE METHOD 활용

상태코드는 대부분 200을 사용하고 상황에 따라 204를 사용한다.

PUT 요청에 리소스가 있는 경우

100번째 멤버를 제거하기 위해 DELETE로 전달
서버에서 요청을 받고 데이터베이스의 해당 리소스를 제거
서버에서 클라이어트로 응답을 해준다. 그러면 클라이언트에서 정상적으로 받으면 200 OK status를 가지며, 회원정보를 얻게 된다.

PUT 요청에 리소스가 없는 경우

100번 유저의 리소스를 교체하겠다는 요청을 보낸다.
기존에 데이터가 없다면 POST 와 같이 신규로 생성

PUT 요청에 일부 리소스만 변경하길 원할 경우

age만 50으로 변경하려고 해당 데이터를 PUT으로 전달한다.
하지만 기존 데이터가 완전히 대체되어 이름 데이터가 삭제된다. (이때는 PATCH 메소드를 이용해야 한다)

3) HTTP 상태 코드

(1) : 1xx : informational response(조건부 응답)

100 Continue(계속) : 지금까지의 상태가 괜찮으며 클라이언트가 계속해서 요청을 하거나 이미 요청을 완료한 경우에는 무시해도 되는 것
101 Switching Protocol(프로토콜 전환) : 클라이언트가 보낸 Upgrade 요청 헤더에 대한 응답에 들어가며 서버에서 프로토콜을 변경할 것
102 Processing (처리, WebDAV) : 서버가 요청을 수신하였으며 이를 처리하고 있지만, 아직 제대로 된 응답을 알려줄 수 없음
103 Early Hints (사전 도움) : 주로 Link 헤더와 함께 사용되어 서버가 응답을 준비하는 동안 사용자 에이전트가(user agent) 사전 로딩(preloading)을 시작할 수 있도록 함

(2) : 2xx Success(성공)

201 Created(작성됨) : 요청이 성공적이었으며 그 결과로 새로운 리소스가 생성됐다. 이 응답은 일반적으로 POST 요청 또는 일부 PUT 요청 이후에 따라옴.
202 Accepted(허용됨) : 요청을 수신하였지만 그에 응하여 행동할 수 없다. 이 응답은 요청 처리에 대한 결과를 이후에 HTTP로 비동기 응답을 보내는 것에 대해서 명확하게 명시하지 않음
203 Non-Authoritative Information(신뢰할 수 없는 정보) : 메타 정보 세트가 오리진 서버의 것과 일치하지 않지만 로컬이나 서드 파티 복사본에서 모아졌음을 의미한다. 이러한 조건에서는 이 응답이 아니라 200 OK 응답을 반드시 우선된다.
204 No Content(내용 없음) : 요청에 대해서 보내줄 수 있는 콘텐츠가 없지만, 헤더는 의미있을 수 있다. 사용자-에이전트는 리소스가 캐시 된 헤더를 새로운 것으로 업데이트할 수 있다.

(3) : 3xx Redirection(리다이렉션, 경로 재지정)

301 Moved Permanently(영구적 이동) : 요청한 리소스의 URI가 변경되었음을 의미
304 Not Modified(변경 없음) : 캐시를 목적으로 사용된다. 이것은 클라이언트에게 응답이 수정되지 않았음을 알려주며, 그러므로 클라이언트는 계속해서 응답의 캐시 된 버전을 사용할 수 있다.

(4) : 4xx Client Error(클라이언트 오류)

400 Bad Request(잘못된 요청) : 잘못된 문법으로 인하여 서버가 요청을 이해할 수 없음
401 Unauthorized(권한 없음) : HTTP 표준에서는 "미승인(unauthorized)"를 명확히 하고 있지만, 의미상 이 응답은 "비인증(unauthenticated)"을 의미
403 Forbidden(접근 금지) : 클라이언트가 콘텐츠에 접근할 권리를 가지고 있지 않음.(401과 다른 점은 서버가 클라이언트가 누구인지 알고 있음)
404 Not Found(찾을 수 없음) : 서버가 요청받은 리소스를 찾을 수 없다. 브라우저에서는 알려지지 않은 URL을 의미
405 Method Not Allowed(허용되지 않은 메서드) : 요청에 지정된 메서드가 URI로 표시된 리소스에 허용되지 않음
408 Request Timeout(요청 시간 초과) : 응답은 요청을 한지 시간이 오래된 연결에 일부 서버가 전송하며, 어떨 때에는 이전에 클라이언트로부터 어떠한 요청이 없었다고 하더라도 보내지기도 함

(5) : 5xx Server Error(서버 오류)

500(내부 서버 오류) : 서버에 오류가 발생하여 요청을 수행할 수 없음.
501(구현되지 않음) : 서버에 요청을 수행할 수 있는 기능이 없음.
502 (Bad Gateway, 불량 게이트웨이) : 서버가 게이트웨이나 프록시 역할을 하고 있거나 또는 업스트림 서버에서 잘못된 응답을 받음.
503(서비스를 사용할 수 없음) : 서버가 오버로드되었거나 유지관리를 위해 다운되었기 때문에 현재 서버를 사용할 수 없음.
504(게이트웨이 시간초과) : 서버가 게이트웨이나 프록시 역할을 하고 있거나 또는 업스트림 서버에서 제때 요청을 받지 못함.

4) CORS(교차 출처 리소스 공유)

교차 출처 리소스 공유(Cross-Origin Resource Sharing, CORS)는 추가 HTTP헤더를 사용하여, 한 출처에서 실행 중인 웹 애플리케이션이 다른 출처의 선택한 자원에 접근할 수 있는 권한을 부여하도록 브라우저에 알려주는 체제

교차 출처 리소스 공유 (CORS) - HTTP | MDN

(1) 동일 출처 정책 (Same-Origin Policy) : 동일한 출처에 대한 정책

출처(Origin)의 동일함은 두 URL의 구성 요소 중 Protocol(Scheme), Host, Port 이 3가지만 동일 하다면 동일 출처로 판단

출처를 비교하는 로직은 서버에 구현된 스펙이 아닌 브라우저에 구현된 스펙임

브라우저가 정책으로 차단을 한다는 말은, 브라우저를 통하지 않고 서버 간에 통신을 할때는 정책이 적용되지 않는다는 말과 같음.

즉, 클라이언트 단 코드에서 API 요청을 하는게 아니라, 서버 단 코드에서 다른 출처의 서버로 API 요청을 하면 CORS 에러로부터 자유로워짐.

그래서 이를 이용한 프록시(Proxy) 서버라는 것이 있음.

(2) 교차 출처 리소스 공유 (Cross-Origin Resource Sharing, CORS) : 다른 출처의 리소스 공유에 대한 허용/비허용 정책

브라우저의 CORS 기본 동작

클라이언트에서 HTTP요청의 헤더에 Origin을 담아 전달
서버는 응답헤더에 Access-Control-Allow-Origin을 담아 클라이언트로 전달
클라이언트에서 Origin과 서버가 보내준 Access-Control-Allow-Origin을 비교한다.

CORS 해결책은 서버의 허용이 필요 ⇒ 서버에서 ~~Access-Control-Allow-Origin~~ 헤더에 허용할 출처를 기재해서 클라이언트에 응답하면 됌