[WEB] 웹 서버(Web Server)와 REST API 개념 정리

이 글은 웹 서버의 개념과 REST API의 개념에 대해 정리한 글입니다.

---

웹 서버 (Web Server)

웹 서버

• 웹 서버는 하드웨어와 소프트웨어 차원에서 모두 사용되는 용어
  • 하드웨어 : 웹 요청을 수신하고 처리를 수행하는 물리적 서버 컴퓨터
  • 소프트웨어 : 웹 요청(HTTP 프로토콜 기반)을 받아들이고, 적절한 응답을 반환하는 프로그램
• 일반적으로 웹 서버라고 하면 소프트웨어를 가리키는 경우가 많음

웹 서버의 작동 원리

클라이언트 - 서버 모델

1. 클라이언트(웹 브라우저 등)는 특정 리소스를 요청하기 위해 HTTP 요청을 서버로 전송
2. 서버는 클라이언트로부터 받은 요청을 분석하여 적절한 응답(HTML, JSON, 파일 등)을 생성
3. 서버는 생성된 응답을 HTTP 응답 형태로 클라이언트에 반환
4. 클라이언트는 응답을 해석하여 화면에 출력하거나 추가 처리를 수행

HTTP 프로토콜

HTTP 프로토콜 개요

• 클라이언트-서버 모델
  • 웹 브라우저(클라이언트)는 웹 서버에 요청(request)을 보내고, 서버는 해당 요청에 대한 응답(response)을 전송
  • 주로 TCP(전송 계층) 연결 위에서 수행
• 무상태성 (Stateless)
  • HTTP는 기본적으로 무상태(stateless) 프로토콜이므로, 서버는 한 번의 요청에 대한 처리 후 클라이언트 상태를 유지하지 않음
  • 로그인 정보나 장바구니 같은 상태를 유지하기 위해 쿠키(cookie), 세션(session), 토큰(JWT) 등 추가적인 매커니즘을 사용
• 표준 포트
  • 일반적으로 HTTP는 80번 포트, HTTPS는 443번 포트를 기본값으로 사용

HTTP 요청 (Request)

POST /api/users HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 ...
Content-Type: application/json
Content-Length: 53

{
  "name": "Alice",
  "email": "alice@example.com"
}

• 시작줄 (request line) : 매서드(GET, POST, PUT, DELETE 등), 요청 URL, HTTP 버전을 포함
• 헤더 (header) : 요청에 대한 부가 정보(메타데이터) 전달
• 공백 줄 (blank line) : 헤더가 끝났음을 알리는 빈 줄
• 본문 (body, optional) : POST, PUT 등에서 전송할 데이터 (양식 정보, JSON, 파일 등)

주요 HTTP 요청 메서드

HTTP request methods (출처: https://assertible.com/blog/7-http-methods-every-web-developer-should-know-and-how-to-test-them)

• GET
  • 서버에서 리소스를 조회할 때 사용
  • 요청 본문(body)을 두지 않고, 요청 파라미터를 쿼리 스트링(query string)으로 전달 가능
  • CRUD 중 R(read)에 해당하는 HTTP 요청 메서드
• POST
  • 서버에 리소스(데이터)를 생성하거나, 데이터 처리 요청을 보낼 때 사용
  • 요청 본문(body)에 전송할 데이터를 담아 전송 수 있음 (JSON, XML, Form Data 등)
  • CRUD 중 C(create)에 해당하는 HTTP 요청 메서드
• PUT
  • 서버 상의 기존 리소스(데이터)를 전체 수정(교체)할 때 사용
  • 보통 요청 본문(body)에 수정할 데이터(전체 리소스)를 담아 전송
• PATCH
  • 리소스(데이터)의 일부만 변경할 때 사용
  • PUT과 달리 전체 대신 부분 업데이트에 특화
  • CRUD 중 U(update)에 해당하는 HTTP 요청 메서드
• DELETE
  • 서버 상의 리소스(데이터)를 삭제할 때 사용
  • CRUD 중 D(delete)에 해당하는 HTTP 요청 메서드

HTTP 응답 (Response)

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 45

{
  "id": 123,
  "name": "Alice",
  "email": "alice@example.com"
}

• 시작 줄 (status line) : HTTP 버전, 상태 코드, 상태 메시지
• 헤더 (header) : 응답 관련 부가 정보
• 공백 줄 (blank line)
• 본문 (body, optional) : 요청에 대한 결과 데이터를 포함 (HTML, JSON, XML, 파일 등)

주요 HTTP 상태 코드

• 1xx (information) : 정보 전달 (일반적으로 실무에서 거의 사용되지 않음)
• 2xx (Success) : 요청 성공
• 3xx (Redirection) : 요청한 리소스(데이터)의 위치 변경 (리다이렉트)
• 4xx (Client Error) : 클라이언트 측 오류 (대표적으로 404 ERROR가 있음)
• 5xx (Serever Error) : 서버 측 오류

---

REST API

REST (Representational State Transfer)

• 분산 하이퍼미디어 시스템을 위한 아키텍처 스타일 중 하나로, 웹에서 리소스를 어떻게 정의하고 주소(URI)로 표현할지에 대한 철학이자 설계 방식

특징

• 클라이언트-서버 구조 : 클라이언트와 서버를 명확히 분리
• 무상태성 (stateless) : 클라이언트의 상태를 서버가 유지하지 않음 (모든 요청은 독립적)
• 캐시 처리 가능 (cacheable) : HTTP의 기본 캐시 구조 활용
• 계층화 (layered system) : 중간 계층(프록시 등)을 둘 수 있음
• 코드 온 디멘드 (code on demand, 선택) : 서버가 클라이언트로 스크립트 등을 전달해 실행
• 인터페이스 일관성 (uniform interface) : URL, HTTP 메서드, HTTP 표준 등을 통해 일관성 있는 인터페이스 추구

API (Application Programming Interface)

• Application Programming Interface의 약자로, 소프트웨어 인터페이스를 소스코드 형태로 구현한 것을 의미
• 서로 다른 소프트웨어끼리 상호작용을 할 수 있도록 기능, 데이터, 서비스 등을 제공하는 명확한 규칙(interface)을 정의한 것

RESTful API

• REST 아키텍처 스타일 양식을 최대한 충실히 지킨 API 설계를 의미
• HTTP 요청 메서드(동사)에 따라 서버의 리소스(명사)를 처리하는 방식이 달라짐
• URI(Uniform Resource Identifier)는 리소스 식별자를 의미하며, 주로 URL(Uniform Resource Locator) 형태를 사용 

좋은 RESTful API 설계

• 리소스 이름은 복수 형태로 표현 : /users, /menus, /products
• 특정 항목 조회 시 식별자(ex. id) 사용 : /users/123, /products/10
• 중첩 구조 사용 : /users/123/orders/256

REST API의 장점

• 클라이언트-서버의 의존도가 낮음 : 서버와 클라이언트가 독립적으로 개발 및 배포 가능
• 확장성 : HTTP 표준만 지원하면 다양한 플랫폼(웹, 모바일, IoT 등)에서 공통된 방식으로 접근 가능
• 유연성과 단순성 : URI, HTTP 메서드, 상태 코드를 일관되게 적용하면 구조 파악이 용이함