[9일차] 웹 백엔드 아키텍처와 RESTful API 설계 규칙

백엔드 아키텍처 개요

본 섹션에서는 웹 서비스의 표준 아키텍처 구성요소를 체계적으로 설명한다. 웹 서비스 아키텍처는 프론트엔드, 웹 서버, 웹 애플리케이션 서버, 데이터베이스로 구성된다.

• 프론트엔드: 사용자 인터페이스를 제공하는 클라이언트 측 구성요소(브라우저, 모바일 애플리케이션 등)이다.
• 웹 서버: 클라이언트 요청을 수신하여 적절한 웹 애플리케이션 서버로 라우팅하는 중개자 역할을 한다.
• 웹 애플리케이션 서버: 핵심 비즈니스 로직을 처리하고 데이터베이스와의 통신을 관리한다.
• 데이터베이스: 구조화된 데이터 저장소로서 영구적인 정보 보관 및 효율적인 검색 기능을 제공한다.

각 계층 간 통신은 표준화된 요청-응답 패턴을 따른다. 엔터프라이즈 환경에서는 이러한 구성요소가 다중 서버와 네트워크에 분산되어 있다.

---

API의 개념과 역할

• API(Application Programming Interface)는 서로 다른 소프트웨어 시스템 간의 상호작용을 가능하게 하는 명확하게 정의된 통신 계약이다.
• 현대적인 웹 개발에서는 프론트엔드와 백엔드 간의 데이터 교환이 API를 통해 구조화된 방식으로 이루어진다.
• 실제 적용 사례:
  • 클라이언트가 /api/products 엔드포인트로 요청하면 서버는 정형화된 JSON 형식으로 상품 정보를 응답한다.

---

REST(RESTful) API의 정의 및 주요 특징

REST는 "Representational State Transfer"의 약자로 웹 서비스 아키텍처를 위한 설계 원칙이다.
HTTP 프로토콜과 URI 체계와 같은 웹의 기존 인프라를 최적으로 활용하는 효율적인 자원 중심 아키텍처 패러다임이다.

RESTful API란?

REST 아키텍처 원칙을 엄격히 준수하여 구현된 인터페이스를 의미한다.

REST 아키텍처의 핵심 원칙과 특징은 다음과 같다.

1. 무상태성(Stateless)

• 모든 요청은 독립적으로 처리되어야 하며, 서버는 이전 요청의 정보를 저장하지 않는다.
• 클라이언트가 필요한 상태 정보를 매 요청마다 포함하여 전달해야 한다.
• 이로 인해 서버 확장성과 유지 관리가 쉬워진다.

2. 클라이언트-서버 구조(Client-Server Architecture)

• 클라이언트(프론트엔드)와 서버(백엔드)는 명확하게 역할이 분리되어 있다.
• 클라이언트는 사용자 인터페이스와 사용자 경험을 담당하며, 서버는 데이터 저장과 비즈니스 로직을 처리한다.
• 이러한 구조는 개발의 독립성과 확장성을 높여준다.

3. 계층형 시스템(Layered System)

• REST 시스템은 여러 계층으로 구성될 수 있다.
• 예를 들어, 로드 밸런서, 프록시, 인증 서버 등이 중간 계층으로 들어갈 수 있다.
• 각 계층은 자신의 역할만 수행하며, 클라이언트는 중간에 어떤 계층이 있는지 알 필요가 없다.
• 보안, 캐싱, 로드 밸런싱 등 다양한 기능을 계층적으로 처리할 수 있다.

4. 일관된 인터페이스(Uniform Interface)

• 모든 자원에 대해 일관된 방식으로 요청과 응답을 주고받는다.
• URI, HTTP 메소드, 응답 포맷(JSON 등) 등이 표준화되어 있다.

---

REST API 설계 지침

1. 명사 기반 URL 구조를 채택해야 한다.
   • 예시: /users, /orders, /products/123
2. 의도된 작업은 HTTP 메소드로 표현한다.
   • 조회 작업: GET /users/1
   • 리소스 생성: POST /users
   • 리소스 갱신: PUT /users/1
   • 리소스 제거: DELETE /users/1
3. 표준화된 응답 형식을 구현해야 한다.
4. 관심사 분리 원칙에 따라 클라이언트-서버 역할을 구분해야 한다.
5. 무상태(Stateless) 통신 모델을 적용해야 한다.
   • 각 요청은 컨텍스트에 독립적으로 처리되어야 하며, 서버는 클라이언트 세션 상태를 유지하지 않는다.

---

RESTful API URI 설계 표준 (업계 관행)

• 소문자를 일관되게 사용해야 한다.
  • 권장: /users, /order-items
• 단어 구분은 하이픈(-)으로 표현해야 한다.
  • 권장: /order-items, 비권장: /order_items
• 슬래시(/)는 계층 관계 표현에만 사용하며, 후행 슬래시는 생략해야 한다.
  • 권장: /users/1/orders, 비권장: /users/1/orders/
• 동작 의도(함수명)는 URI에 포함하지 않아야 한다.
  • 권장: /products, 비권장: /get/products
• 파일 확장자는 표기하지 않아야 한다.
  • 권장: /users, 비권장: /users.json
• 리소스 명칭은 복수형으로 사용해야 한다.
  • 권장: /users, /products, /orders

---

HTTP 메소드 개요

HTTP 프로토콜은 클라이언트 요청의 의도를 명확히 전달하기 위한 다양한 메소드를 제공한다.

Method	기능	사용 예시
GET	리소스 조회	GET /users/1
POST	리소스 생성	POST /users
PUT	리소스 전체 갱신	PUT /users/1
PATCH	리소스 부분 갱신	PATCH /users/1
DELETE	리소스 삭제	DELETE /users/1

---

URL 구조 분석

URL은 리소스의 위치와 식별 정보를 명확하게 표현한다.

쇼핑몰 URL 구조 분석:

shop.example.com/products/12345

• shop.example.com: 도메인 이름(호스트)이다.
• products: 리소스 유형이다.
• 12345: 특정 제품의 고유 식별자이다.

소셜 미디어 URL 구조 예시:

• /profiles: 사용자 프로필 컬렉션이다.
• /profiles/username/photos: 특정 사용자의 사진 컬렉션이다.

표준 RESTful API URI 예시:

• /customers/42/subscriptions: 특정 고객의 구독 정보 컬렉션이다.
• /movies/76/reviews: 특정 영화에 대한 리뷰 모음이다.

---

RESTful API 설계 시 주요 고려사항

• URI에서 동사 표현은 지양해야 한다.
  • 비권장: /getUsers
  • 권장: GET /users
• 서버 측 상태 관리는 지양해야 한다.
  • 인증은 JWT와 같은 토큰 기반 메커니즘으로 구현한다.
• 오류 상태는 표준 HTTP 상태 코드(400, 404, 500 등)를 통해 명확하게 전달해야 한다.

---

참고: RESTful API 설계 실무 예시

요청	설명
GET /products	상품 목록을 조회한다.
POST /products	상품을 등록한다.
GET /products/id	상품 상세 정보를 조회한다. (id=1)
PUT /products/id	상품 전체를 수정한다. (id=1)
DELETE /products/id	상품을 삭제한다. (id=1)

---