HTTP & REST
HTTP
HTTP(HyperText Transfer Protocol)는 인터넷상에서 데이터를 전송하기 위한 프로토콜
TCP/IP 4계층에서 응용 계층에 속함
1. 비연결성(connectionless)
클라이언트에서 요청을 보낸 후 서버로부터 응답을 받으면 연결을 끊음
비연결성은 불특정 다수를 대상으로 하는 서비스에 유리
서버에서 응답을 받고 나서도 연결을 유지하려면 그만큼 자원을 사용
-> 비연결성은 연결을 유지하지 않음으로써 자원 효율적
문제는 연결을 유지하기 않기 때문에 서버가 클라이언트를 기억할 수 없다
또한, 동일한 클라이언트에서 연속적으로 요청이 오면 연결과 연결 해제 과정 반복, 자원 낭비
-> 이를 해결하기 위해 일정 시간 동안 연결을 유지할 수 있도록 HTTP Keep Alive를 사용
따라서 마지막 응답 이후 일정 시간 동안 연결을 유지, 동일한 클라이언트로부터 요청이 오면 연결 과정을 생략
HTTP Keep Alive
HTTP 연결 시 일정 시간 동안 요청을 유지할 수 있도록 사용하는 HTTP 헤더의 일종
클라이언트에서 HTTP 요청을 보낼 때 연결 헤더에 Keep Alive를 추가해서 보내면
서버에서 연결을 유지할 시간을 Keep Alive 헤더에 추가해 응답
2. 무상태(stateless)
서버에서 클라이언트의 상태를 저장하지 않는 것
클라이언트가 이전에 요청한 사항을 서버에 저장 X
따라서 클라이언트는 요청에 필요한 데이터를 모두 가지던가 or 서버가 클라이언트로부터 받은 요청 사항을 모두 저장
각각 쿠키(cookie)와 세션(session)
장점은 서버 확장성이 높다는 점
클라이언트의 요청에 응답하는 서버가 바뀌어도 되기 때문에 서버 계속 확장 가능
따라서 특정 서버에 문제가 생겨 응답하지 못하는 문제점을 보완 가능
+@
쿠키(cookie)
클라이언트의 로컬 웹 브라우저에 저장하는 데이터 파일로, 키와 값을 저장
ex) 웹 사이트의 로그인 정보, 온라인 쇼핑몰의 장바구니
세션(session)
서버에서 클라이언트와의 연결 정보를 저장 및 관리하는 것
서버에 데이터가 저장 -> 보안 면에서는 쿠키보다 좋다 but 접속자가 많을 경우 서버 과부하 가능성
HTTP 메시지의 구조
• 요청 라인(request line): 요청 URI, 요청 방법, HTTP 버전 등
• 상태 라인(status line): 요청에 대한 HTTP 상태 코드와 HTTP 버전
• 헤더(header): 키-값으로 구성된 다수의 헤더 항목
• 빈 줄(blank line): 헤더의 끝을 나타내는 빈 줄로, 헤더와 바디를 구분
• 바디(body): 요청 방법 메서드가 POST인 경우에만 바디가 있음, 그 외 메서드일 때는 비어있음 (관례적으로는)
HTTP 요청 메시지 예시 (Request)
POST /login HTTP/1.1
Host: example.com
Content-Type: application/json
Content-Length: 38
{
"username": "testuser",
"password": "1234"
}
요청 라인: POST /login HTTP/1.1
헤더: Host, Content-Type, Content-Length
빈 줄: 헤더와 바디 구분
바디: JSON 형식 데이터
HTTP 응답 메시지 예시 (Response)
HTTP/1.1 200 OK
Date: Sat, 03 Oct 2025 06:00:00 GMT
Content-Type: application/json
Content-Length: 27
{
"result": "success",
"token": "abcd1234"
}
상태 라인: HTTP/1.1 200 OK
헤더: Date, Content-Type, Content-Length
빈 줄
바디: 서버가 반환한 JSON 데이터
HTTPS
보안 계층인 SSL /TLS 를 이용해 HTTP 의 보안을 강화한 웹 통신 프로토콜
HTTP는 데이터 암호화를 거치지 않고 전송해서 보안에 취약
SSL(Secure Socket Layer)은 넷스케이프(Netscape)에서 개발한 암호화 프로토콜
SSL은 몇 가지 문제점 존, 이를 보완해 새로운 암호화 프로토콜인 TLS(Transport Layer Security)를 개발
현재 HTTPS에서 통용되는 방식은 TLS지만, SSL이라는 명칭이 사라지지 않아서 SSL 또는 SSL/TLS라고 부름
HTTPS의 동작 방식 ( 간략하게)
데이터를 송신할 때 응용 계층에서 보안 계층의 SSL/TLS로 데이터를 보내면 데이터를 암호화해 전송 계층으로 전달
그러면 데이터를 수신할 때 전송 계층에서 보낸 데이터를 보안 계층의 SSL/TLS에서 받아 복호화한 후 응용 계층 전달
+@
SSL/TLS에서는 암호화를 위해 2가지 암호화 방식을 사용
• 대칭 키 암호화 방식
데이터의 암호화와 복호화에 모두 같은 키인 대칭 키를 이용하는 방식
먼저 수신자가 가진 키를 송신자에게 준다. 이때 수신자가 같더라도 송신자가 다르면 이용하는 키도 다름
송신자는 받은 키로 데이터를 암호화한 후 수신자에게 보냄
수신자는 동일한 키로 데이터를 복호화
• 공개 키 암호화 방식
데이터의 암호화와 복호화를 다른 키로 하는 방식
데이터를 암호화할 때는 공개 키, 복호화할 때는 비밀 키를 이용
먼저 수신자는 공개 키를 송신자에게 준다. 이때 송신자가 달라도 공개 키는 같다.
송신자는 수신자에게 받은 키로 데이터를 암호화한다.
수신자는 비밀 키로 송신자에게 받은 데이터를 복호화한다
이 방식은 비밀 키가 있어야만 데이터를 복호화할 수 있어서 공개 키 유출을 염려 X
웹 페이지 접속 과정
① 사용자가 URL을 웹 브라우저에 입력
② 웹 브라우저는 입력한 URL을 바탕으로 DNS(Domain Name System) 서버에 연결할 IP를 요청
③ DNS 서버는 IP 주소를 웹 브라우저에게 응답으로 제공
④ 웹 브라우저는 DNS 서버에서 받은 IP를 통해 웹 서버와 TCP/IP 연결을 하고 HTTP 요청을 보냄
⑤ 웹 서버는 받은 HTTP 요청에 응답. 응답은 웹 페이지와 필요한 리소스를 포함
⑥ 웹 브라우저는 받은 응답을 바탕으로 사용자에게 웹 페이지를 보여줌
REST = Representational State Transfer
HTTP 통신을 활용하기 위해 고안된 아키텍처
Representational = 인터넷상의 자원을 URI(Uniform Resource Identifier)로 나타낼 수 있음을 의미
클라이언트는 URI로 표현된 자원을 HTTP 메서드를 이용해 CRUD(Create, Read, Update, Delete) 연산 가능
State Transfer = 자원의 상태를 주고받는 것, 즉 요청받은 자원의 상태를 전달하는 것
결국 REST -> 자원을 명시해 연산을 수행하고 상태를 주고받는 것
REST 특징
• 일관된 인터페이스
자원을 나타내는 URI를 HTTP 메서드로 조작하는 일관된 인터페이스를 사용
따라서 HTTP를 따르는 모든 플랫폼에서 REST를 사용 가능
• 클라이언트-서버 구조
클라이언트와 서버 간에 요청-응답의 독립적인 구조
클라이언트는 서버에 요청을 보내고 응답을 대기. 서버는 자원을 가지고 있으며 클라이언트의 요청에 응답
• 무상태성
서버에서는 클라이언트의 요청을 저장 X, 관리 X
서버는 클라이언트의 요청에 대한 처리와 응답만 한다.
사용자 인증, 로그인 정보 등은 클라이언트에서 직접 관리
• 캐싱 가능
HTTP 표준을 사용 -> 클라이언트는 이전에 서버에서 받은 응답을 저장, 재사용하는 캐싱(caching) 가능
캐싱은 클라이언트의 많은 요청으로부터 서버 부하 줄임, 클라이언트는 비교적 빨리 응답 수신 가능
• 자체 표현 구조
REST API는 자원, 행위, 표현으로 구성되어 REST API 메시지를 보고 어떤 요청을 하는지 알 수 있음
• 계층형 구조
REST 서버는 다중 계층으로 구성 가능 -> 보안, 암호화와 같은 계층을 추가해 서버에 대한 기능을 유연하게 확장 가능
REST는 이런 특징과 함께 HTTP를 기반으로 하기 때문에 별도의 인프라를 구축할 필요가 없다는 장점
그래서 HTTP 표준을 따르면 REST를 쉽게 사용 가능
하지만 HTTP 메서드를 사용해 자원에 대한 연산을 처리하므로 동작이 한정적이라는 단점
+@
• URI(Uniform Resource Identifier)
인터넷에 있는 자원을 나타내는 주소
URI는 인터넷에서 요구하는 기본 조건으로 인터넷 프로토콜에 항상 붙어 다님. URI의 하위 개념으로 URL, URN
• URL(Uniform Resource Locator)
인터넷에서 자원의 위치를 알 수 있는 규약이다. 웹 사이트 주소와 인터넷의 모든 자원을 나타낼 수 있다.
• URN(Uniform Resource Name)
자원의 위치 정보가 아닌 실제 자원을 특정한다.
REST API
REST를 기반으로 한 API
API(Application Programming Interface) = 다른 소프트웨어에 서비스를 제공하기 위한 소프트웨어 인터페이스
구조
- 자원 - URI
- 행위 - HTTP 메서드
- 표현 - JSON, XML..
자원의 식별은 URI, 자원에 대한 행위(처리)는 HTTP 메서드, 그리고 전달되는 데이터는 JSON 또는 XML
REST API의 작동 방식
① 클라이언트가 URI로 식별한 자원에 대해 HTTP 메서드를 사용해 REST API로 요청
② REST API가 HTTP 요청 메시지에 실려 서버에 전달
③ 서버에서는 수신한 HTTP 요청 메시지를 바탕으로 요청 사항 처리, HTTP 응답을 반환
응답에는 요청에 대한 처리 성공 여부와 정보를 포함
④ 응답 메시지는 자원에 대한 정보를 JSON 또는 XML 등의 형태로 포함
클라이언트는 해당 형태의 정보를 수신한다
+@ RESTful 하다?
REST 규칙을 최대한 지키며 API를 제공하는 서비스
REST API를 최대한 RESTful하게 사용하려면?
• 자원에 대한 행위는 HTTP 메서드로 나타내야댐
HTTP 메서드나 행위에 대한 표현이 URI에 들어가면 안됨
• HTTP 메서드는 명시적
즉, 요청하려는 목적에 맞게 HTTP 메서드를 사용
POST 메서드로 Create뿐 아니라 Update 같은 연산을 하면 명시적이라고 볼 수 없음
• URI 경로는 슬래시(/)로 계층 관계를 표현, URI 마지막에 슬래시가 들어가면 안됨
• URI 경로에는 언더바(_)를 사용 X, 소문자 사용을 지향
HTTP 메서드
클라이언트가 요청을 보낼 때 요청에 포함된 HTTP 메서드는 요청의 종류와 목적을 나타냄
• POST: 데이터를 생성할 때
• GET: 데이터를 조회할 때
• PUT: 데이터를 갱신할 때
• DELETE: 데이터를 제거할 때
+@
• PATCH: 데이터를 일부 갱신할 때 사용
• HEAD: GET과 동일하게 데이터를 조회할 때 사용, HTTP 메시지에 바디를 포함하지 않고 헤더로만 응답
• TRACE: 클라이언트의 요청 메시지를 그대로 반환(루프백 메시지)하면서 쿠키 및 세션 값을 포함해 응답
• CONNECT: 요청한 자원을 양방향으로 연결하는 데 사용하고, SSL을 사용하는 웹 사이트에 접속 가능
• OPTION: 서버가 지원하는 HTTP 메서드를 메시지 헤더에 포함해 응답