Spring Framework

1. 스프링 시큐리티
2. Spring Data JPA 사용하기
3. 첫 번째 Spring Boot 애플리케이션
4. Spring Boot 개요
5. Restful Web Service with Spring
6. RESTful Web Service
7. Logging with SLF4J and Logback
8. Spring Entity Mapping
9. Spring JPA (Java Persistence API)
10. Spring MVC Web Form
11. Spring MVC 패턴
12. Spring 의존성 주입
13. Spring 개요

목록보기

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)

5. 무상태성(Statelessness)

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

무상태의 장점

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

인증 방식 비교

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

6. 캐싱(Caching)

주요 캐시 헤더

Cache-Control 지시자

캐시 사용 예시

• 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 상태 코드 사용