[Spring] HTTP (3)

📦 HTTP Header란?

• 클라이언트와 서버가 요청/응답 시 부가 정보를 전달하는 메커니즘
  (데이터 형식, 인증, 브라우저 정보, 언어, 캐시 정책 등)

✅ Header 구조

field-name: field-value

• field-name: 대소문자 구분 없음
• OWS: 공백 허용
• 한 줄에 하나씩 작성, 텍스트 기반
• HTTP 전송에 필요한 모든 부가 정보를 표현할 수 있음

실제 HTTP Header 확인하는 법

• 개발자 도구 (F12) → Network 탭 클릭 → Fetch/XHR 탭 클릭 → 우측 Header 정보

---

🔧 주요 HTTP Header 분류 및 역할

종류	설명	예시
📄 표현 헤더	데이터 형식, 언어 등 표현 관련	Content-Type, Content-Encoding, Content-Language
⚙️ 컨텐츠 협상	클라이언트의 선호 표현 전달	Accept, Accept-Language, Accept-Encoding
📌 일반 정보	브라우저/레퍼러/서버 정보 등	User-Agent, Referer, Server, Date
🔐 인증	인증 방식 및 정보 전달	Authorization, WWW-Authenticate
🍪 쿠키	상태 유지를 위한 데이터	Set-Cookie, Cookie, Secure, HttpOnly, SameSite
💾 캐시	데이터 재전송 최소화	Cache-Control, ETag, Last-Modified, If-Modified-Since
📍 특별 정보	도메인, 리다이렉트 URI 등	Host, Location, Allow, Retry-After

💡 모든 헤더는 필요할 때 참고해서 사용하면 됨

---

🌐 REST란?

• 자원(Resource)을 고유 URI로 식별하고,
  HTTP 메서드를 활용해 CRUD 동작을 표현하는 아키텍처 스타일

📏 RESTful API란?

• REST 원칙을 잘 지킨 HTTP 기반 API
• 자원을 URI로 표현하고, HTTP 메서드로 조작

> 참고 자료
REST API URI Naming Conventions and Best Practices

🔑 RESTful API 설계 원칙 요약

항목	원칙
리소스 표현	명사 사용 (예: /users)
복수형 사용	/user ❌ → /users ⭕
메서드 활용	CRUD는 URI 대신 HTTP Method로 표현
동사 지양	/getUser ❌, /users + GET ⭕
구조적 URI	계층 표현 (예: /users/1/posts)
Query Param	정렬, 필터, 페이지네이션 등
예외 처리	일관된 응답 포맷 제공
보안 정보	URI에 포함 ❌ (ex: /users/password)

🧱 REST 성숙도 모델 (Richardson Maturity Model)

> Level 0

• 웹 서비스를 제공하기 위해 URL만 매핑해 놓은 상태

• 요청 예시(모든 요청이 단일 URI로 전송됨)

POST /operation
{
    "operation": "createUser",
    "data": {
        "name": "sparta",
        "password": "codingclub"
    }
}

> Level 1

• 외부로 공개하려는 리소스에 대해서 의미있는 URL로 표현하기 시작한 단계
• 적절한 패턴을 가지고 작성되었지만, HTTP의 메소드별로 서비스를 구분하여 사용하고 있지는 않음
  • 즉, 서비스 형태나 작업의 종류에 맞추어 적절한 HTTP 메소드를 지정하고 있지 않음
• 사용자의 요청을 GET, POST로 대부분 처리하고 에러를 반환

• 요청 예시(리소스에 대해 분리된 엔드포인트를 가짐)

POST /users
{
    "name": "sparta",
    "password": "codingclub"
}

> Level 2

• 우리가 제공하고자 하는 리소스를 적절하게 용도와 상태에 따라서 HTTP Methods에 맞게 설계하고 서비스하는 단계
  • 만약 리소스의 상태가 읽기 용도로 사용되는 데이터라고 한다면, GET Method 사용
  • 새로운 리소스를 추가하는 경우는 POST Method
  • 기존 리소스의 상태를 변경하기 위해서는 PUT, PATCH Method
  • 리소스를 삭제하고자 할 때에는 Delete Method를 사용하여 서비스의 상태를 표현
• RESTful Service의 DB에 저장된 리소스를 확인하고 이러한 데이터를 조작하기 위해서 CRUD와 매칭되는 HTTP Methods를 이용하여 서비스 하는 것을 Level 2단계라고 함
• HTTP의 메소드를 이용하여 리소스의 상태를 구분하여 서비스 하게 되면 비슷한 이름의 URI라 하더라도 HTTP Method에 따라서 다른 형태의 서비스를 제공할 수 있게 됨

• 요청 예시(HTTP Method 활용)

GET /users/123     // 특정 사용자 조회

POST /users        // 사용자 생성
{
    "name": "sparta",
    "password": "codingclub"
}

PUT /users/123     // 사용자 정보 수정
{
    "name": "java",
    "password": "spring"
}

DELETE /users/123  // 사용자 삭제

> Level 3

• 데이터를 가지고 그 다음 작업에서 어떠한 작업을 할 수 있는지 상태 정보를 함께 넘겨줌
• 클라이언트 측에서는 서버가 제공하는 서비스를 일일이 찾는 수고를 겪지 않아도 됨
• 엔드포인트만 가지고 있으면 서버가 제공할 수 있는 다음, 그 다음 URI 값을 알 수 있음

• 요청 예시(응답 내에 링크를 포함한다)

GET /users/123
{
    "id": 123,
    "name": "sparta",
    "links": {
        "self": "/users/123",
        "update": "/users/123",
        "delete": "/users/123"
    }
}

레벨	설명	특징
Level 0	단일 URI + 동작을 Body로 구분	POST /operation
Level 1	리소스마다 URI 분리	POST /users
Level 2	HTTP Method 적극 활용	GET /users/123, DELETE /users/123
Level 3	HATEOAS 지원	응답에 다음 동작 URI 포함

→ 현실에서는 대부분 Level 2까지 도달하는 것이 일반적이며, Level 3(HATEOAS)은 일부 대형 시스템에서 사용

✅ HATEOAS란?

• 응답에 다음 동작 가능한 링크 정보를 포함하는 방식
  → 클라이언트는 서버가 제공하는 링크만 따라도 앱을 탐색할 수 있음

GET /users/123
{
  "id": 123,
  "name": "sparta",
  "links": {
    "self": "/users/123",
    "update": "/users/123",
    "delete": "/users/123"
  }
}