RESTful Web Service

2025년 05월 31일

7분

Spring Framework

교과목 내용을 정리하기 위한 글입니다. 틀린 내용이 있을 수 있으니 참고하세요

REST란?

REST는 REpresentational State Transfer의 약자로, 웹 서비스를 개발하기 위한 아키텍처 스타일입니다. 웹 표준 기반 아키텍처로, HTTP 프로토콜을 사용해 데이터 통신을 수행합니다.

자원(Resource)에 공통 인터페이스(HTTP 표준 메서드)를 통해 접근
예시 URI: http://weather.example.com/seoul → 서울의 날씨 자원 접근

REST 서버와 클라이언트

서버: 자원을 제공
클라이언트: 자원을 접근·표현
각 자원은 URI(글로벌 ID)로 식별
자원 표현 방식: 텍스트, JSON, XML 등

RESTful 웹 서비스란?

REST 아키텍처를 기반으로 구축된 웹 서비스를 RESTful 웹 서비스라 합니다. 플랫폼에 독립적이며 클라이언트·서버 구조를 분리합니다.

POST /things            # 자원 생성 (CREATE)
→ 201 CREATED
 
GET  /things/13         # 자원 조회 (READ)
→ 200 OK
 
PUT  /things/13         # 자원 수정 (UPDATE)
→ 200 OK
 
DELETE /things/13       # 자원 삭제 (DELETE)
→ 204 No Content

핵심 패턴: 메서드(명령) + 자원 → 응답 메시지

1. 자원(Resources) 표현

자원은 다양한 포맷으로 표현될 수 있습니다.

<user>
  <id>1</id>
  <name>Mahesh</name>
  <profession>Teacher</profession>
</user>

{
  "id": 1,
  "name": "Mahesh",
  "profession": "Teacher"
}

JSON: 객체는 중괄호 {} 로 정의, 이름/값 쌍으로 구성
값 유형: 숫자, 문자열, 불리언, 배열, 객체, null

2. 메시지(Messages)

2.1 HTTP 요청(Request)

HTTP 요청은 다음 주요 요소로 구성됩니다:

메서드: GET, POST, PUT, DELETE 등
URI: 자원 식별자
HTTP 버전: 예: HTTP/1.1
헤더: 메타데이터 (클라이언트 유형, 수용 포맷, 캐시 등)
본문(Body): 자원 표현

2.2 HTTP 응답(Response)

HTTP 응답은 다음 요소로 구성됩니다:

상태 코드: 200 OK, 404 Not Found 등
HTTP 버전: 예: HTTP/1.1
헤더: 메타데이터 (콘텐츠 길이, 타입 등)
본문(Body): 자원 표현

2.3 콘텐츠 협상(Content Negotiation)

클라이언트: Accept 헤더로 선호하는 표현 방식 제시
서버: Content-Type 헤더로 실제 전송 포맷 지정

Accept: text/html, application/json
Content-Type: application/json; charset=UTF-8

2.4 상태 코드(Status Codes)

2xx 성공 (200 OK, 201 Created)
3xx 리다이렉션 (303 See Other)
4xx 클라이언트 오류 (404 Not Found)
5xx 서버 오류 (500 Internal Server Error)

3. URI 설계(Addressing)

표준 URI 규칙

복수형 명사 사용: /users
소문자 사용, 공백 대신 - 또는 _
구버전 호환성을 위해 변경 시 300 리다이렉트 사용
HTTP 메서드로 작업 구분, URI에 동작 이름 포함 금지

# 나쁜 예
GET /.../getUser/1
 
# 좋은 예
GET /.../users/1

4. HTTP 메서드와 CRUD 매핑(Methods)

메서드	URI	설명
GET	`/estore/users`	사용자 목록 조회
GET	`/estore/users/1`	ID=1 사용자 조회
POST	`/estore/users`	새 사용자 생성 (ID 서버 할당)
PUT	`/estore/users/2`	ID=2 사용자 업데이트
DELETE	`/estore/users/1`	ID=1 사용자 삭제
OPTIONS	`/estore/users`	지원 메서드 목록 조회
HEAD	`/estore/users`	헤더만 반환, Body 없음

5. 무상태성(Statelessness)

서버는 클라이언트 상태(세션, 설정 등)를 저장하지 않음

무상태의 장점

각 요청 독립 처리
서버 측 상태 관리 불필요 → 설계 단순화
HTTP 프로토콜과 자연스럽게 호환

인증 방식 비교

인증 방식	상태 관리	설명
세션 기반	Stateful	서버가 사용자 세션 데이터 저장
토큰 기반 (JWT)	Stateless	서버에 상태 비저장, 토큰 서명 검증만 수행

# JWT 토큰 인증 흐름
1. 서버가 사용자 정보로 JWT 생성·서명 → 클라이언트 전달
2. 클라이언트가 요청 시 JWT 헤더에 포함
3. 서버가 서명 검증 후 요청 처리

6. 캐싱(Caching)

주요 캐시 헤더

헤더	설명
Date	자원 생성 시각
Last-Modified	자원 마지막 수정 시각
Cache-Control	캐시 제어 기본 헤더
Expires	캐시 만료 일시

Cache-Control 지시자

지시자	의미
public	모든 캐시 가능한 컴포넌트에 허용
private	클라이언트 전용 캐시만 허용
no-store	어떤 캐시에도 저장 금지
max-age=﹤초﹥	지정 초만큼 캐시 유효
must-revalidate	만료 시 서버 재검증 필요

캐시 사용 예시

max-age=120: 120초 동안 캐시 유효 후 재요청
정적 콘텐츠(이미지/CSS/JS): 2~3일 캐시 권장
동적 콘텐츠: 몇 시간 단위 캐시

ETag 기반 검증

서버는 자원 버전에 ETag 할당
클라이언트가 If-None-Match에 이전 ETag 전송
서버가 일치 시 304 Not Modified 응답 → 클라이언트 캐시 사용

7. 보안(Security)

입력 검증: 서버에서 SQL Injection 등 공격 방어
URL에 민감 정보 금지: 사용자명·비밀번호는 POST로 전달
메서드 제한: 특정 URL에 PUT, DELETE 등 제한
일반화된 오류 메시지: 403 등 HTTP 상태 코드 사용

베스트 프랙티스: 적절한 인증·인가, HTTPS 사용, 과도한 정보 노출 방지