Spring (2) HTTP

destro·2025년 4월 24일

2. Spring

목록 보기

2/17

1. HTTP

💡 참고자료 : 웹 개발자라면 알고 있어야 할 HTTP의 진화 과정

TEXT, IMAGE, FILE, HTML, JSON 등 다양한 형태의 데이터가 HTTP를 통해 전송
HTTP는 대부분 HTTP/1.1 (TCP) 버전을 사용. HTTP/2, HTTP/3 (UDP)의 사용량도 증가하는 추세
클라이언트 to 서버(요청), 서버 to 클라이언트(응답), 서버 to 서버간의 데이터 통신에도 사용됨

📌 HTTP 동작 순서

클라이언트 : Request(요청) 보냄 → 응답 기다림
서버 : 요청에 대한 처리 수행 → 결과 Response(응답)

2. HTTP 특징

Ⅰ. 클라이언트와 서버 구조

기존 : 클라이언트, 서버가 구분되어있지 않음
→ 클라이언트는 UI에 중점을 두도록 하고 서버는 데이터, 비지니스 로직을 담당하도록 함
결과 : 클라이언트, 서버가 각자 독립적으로 발전함

Ⅱ. 무상태 (Stateless)

서버는 클라이언트의 상태를 보존하지 않음
- 장점 : Scale Out 수평 확장성이 높고 갑자기 요청량이 증가해도 서버증설이 쉬움
- 단점 : 클라이언트가 데이터를 추가적으로 전송해야 함
- 한계점 : 무상태로 설계할 수 없는 경우, 로그인을 해야하는 경우

Ⅲ. 비연결 (Connectionless)

HTTP는 연결을 유지하지 않는 모델
- 장점 : 서버 자원을 효율적으로 사용
- 단점
  - 요청이 추가되면 연결(3 way handshake)을 새로 해야함 → 요청에 대한 응답 시간 증가
  - 웹 사이트의 HTML, CSS, JS, 이미지 등의 정적 자원 모두를 다시 다운로드
  - 현재는 HTTP 지속연결(Persistent Connections)로 문제를 해결함

⭐ HTTP 지속연결(Persistent Connections)
   
  - 하나의 요청에 필요한 요청들이 모두 응답될 때까지 연결 유지
  - 연결을 한번만 맺고 끊기 때문에, Connectionless 방식보다 연결 횟수가 적음 → 속도가 빨라짐
    ex) HTML 요청 + CSS 요청 + JS 요청 + 이미지 요청

3. HTTP Message

💡 공식 스펙

HTTP Message는 요청 메세지, 응답 메세지 두 가지 종류가 있고 구조가 각각 다르다.

📌 HTTP Message 구조

Ⅰ. HTTP 요청 메세지(Request Message)

Start Line
- HTTP Method
  - GET : 요청의 의도를 가진 GET, POST, PUT, PATCH, DELETE 등
    - Create - POST
    - Read - GET
    - Update - PUT(전체), PATCH(일부)
    - Delete - DELETE
    - Request Target
- path
  - /event : HTTP Request가 전송되는 대상, 절대 경로(”/”로 시작하는 경로)
  - Query String(= Query Parameter) 값 포함 ex) /search?keyword=sparta
- HTTP Version
  - 1.1 : HTTP Version (1.1, 2, 3 등)
Header
- Host : spartacodingclub.kr
- field-name : OWS field-value OWS (OWS : 띄어쓰기 허용) 구조 대소문자 구분 X
- 서버가 값을 알고 있으면 임의의 Header 추가 가능
- 요청의 추가 정보들을 가지고 있음
  ex) Message Body 내용, 크기, 인증, 브라우저 정보, 서버 정보 등
Empty Line
- 공백 한 줄 필수 값
Message Body
- 실제 전송하는 데이터가 담겨 있는 부분 HTML, 이미지, JSON 등 byte로 표현되는 모든 데이터
- 요청 시 GET의 경우 Message Body가 지원되지 않는 경우가 많아 권장하지 않음

Ⅱ. HTTP 응답 메세지(Response Message)

Start Line
- HTTP Version
- Status Code : 요청 성공 / 실패 실패여부
- Status Text : 코드와 함께 전달될 메세지
Header
- Response에서만 사용되는 Header 값들이 따로 존재
Empty Line
- 공백 한줄 필수 값
Message Body
- 실제 전송하는 데이터가 담겨 있는 부분
- 만약 전송할 데이터가 없다면, Body가 공백으로 존재

4. HTTP Method

📚 클라이언트 - 서버 사이에 이루어지는 요청, 응답 데이터를 전송하는 방식을 뜻한다.

⭐ 주요 Method ⭐

Ⅰ. POST : 리소스 생성

주로 HTML FORM(회원가입, 게시글 작성 등)에 사용
요청 데이터 처리방식 정해진것X (요청 데이터 처리, 조회시 JSON 요청 데이터가 필요한 경우)
Message Body를 통해 요청 데이터를 전달

Ⅱ. GET : 리소스 조회

Query String 미포함 GET의 경우 Message Body가 미지원되는 경우가 많아 권장하지 않음
Query String 포함 서버에 추가 데이터 전송시 Message Body가 아닌 Query String을 사용

Ⅲ. PUT : 리소스 덮어쓰기

POST와는 다르게 클라이언트 측에서 리소스를 식별하여 URI를 지정

기존 리소스가 존재하는 경우 👉 리소스 전체 수정
기존 리소스가 존재하고 일부만 변경하는 경우 기존 리소스 존재시 완전히 덮어쓰기
기존 리소스가 없는 경우 👉 없으면 생성됨

Ⅳ. PATCH : 리소스 부분 수정

Ⅴ. DELETE : 리소스 삭제

Ⅵ. 기타 Method

HEAD 👉 GET에서 Message Body를 제외하고 상태 줄과 헤더만 반환
OPTIONS 👉 대상 리소스에 대한 통신 가능한 Method를 설명
CONNECT 👉 대상 자원으로 식별되는 서버에 대한 터널을 설정 잘 사용하지 않음
TRACE 👉 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행 잘 사용하지 않음

Ⅶ. HTTP Method 속성

📌 HTTP Method별 속성표 Optional : 있을 수 있다

안전성(Safe)
- GET 메소드(조회)는 안전 👉 저장된 데이터를 변환하지 않음
- POST, DELETE, PUT, PATCH는 안전하지 않음 👉 데이터를 생성, 수정, 삭제함
멱등성(Idempotent)
- 한번을 호출하거나 여러번을 호출하거나 항상 동일한 결과
  - POST → 멱등성을 보장하지 않음
    ex) 계좌 송금 2회, 게시판 글쓰기, 회원가입
- 요청이 실패한 경우 재시도 하기위해 필요
  - 항상 결과가 같다면 마음껏 재시도 가능 멱등하지 않으면 중복 요청을 하면 안됨
  - 복구 매커니즘에 사용
    ex) 요청 실패시 서버에서 자동으로 재시도
- 리소스 조회 재요청 중간에 변경 시 👉 멱등성으로 고려하지 않음
  ex) 도서관 책 재고 조회(실시간으로 대여 혹은 판매됨)
캐시가능성(Cacheable) : 재사용을 위해 요청에 대한 응답 저장 가능 여부
- GET, HEAD, POST 메소드는 캐시 가능 GET, HEAD 정도만 사용
  ex) 변경 가능성이 적은 정적자원(HTML, CSS, IMAGE, JS 등)을 주로 캐싱

💡 캐시(Cache)란?
📚 이미 요청한 데이터를 다시 요청할 때마다 전송하지 않도록 웹에서 임시로 데이터를 보관하는 장소

5. HTTP 상태 코드

📚 HTTP 요청에 대한 처리 상태를 응답하는 코드, Data를 함께 응답.

HTTP Response Message 구조

HTTP Status Code

1xx (정보) 👉 요청 수신 후 처리중인 상태 잘 사용하지 않음
2xx (성공) 👉 정상 처리 완료된 상태
- 200 OK 👉 요청 성공
- 201 Created 👉 새로운 리소스 생성
- 202 Accepted 👉 요청이 수신되었으나 처리가 완료되지 않음 주로 Batch 처리에서 사용
  ex) 설정한 시간마다 반복적으로 동작하는 특정 작업
- 204 No Content 👉 요청은 성공했지만, 응답 데이터가 없음
  ex) 저장, 작성버튼 클릭 시
3xx (리다이렉션) 👉 요청을 완료하려면 추가 행동이 필요한 상태
- 3xx 응답 + Location HTTP Header가 있으면 Location 위치로 리다이렉트
- 영구 리다이렉션 URL 영구 변경 시 기존 URL 사용 X ex) /event → /event1
  - 301 Moved Permanently 👉 요청 메서드가 GET으로 변하고 본문이 제거될 수 있음
  - 308 Permanent Redirect 👉 리다이렉트시 요청 메서드와 본문 유지
- 일시 리다이렉션 URI가 일시적으로 변경된 경우
  ex) 게시글 작성 후 게시글 목록 페이지로 이동, PRG 패턴
  - 302 Found 👉 요청 메서드가 GET으로 변동 가능
    - 모호해서 명확한 303, 307이 등장
    - 이미 사용하고 있는곳이 많음. GET으로 변해도 상관없다면 사용해도 무방
  - 303 See Other 👉 요청 메서드가 GET으로 변경
    - 요청 메서드가 GET으로 변경된다.
  - 307 Temporary Redirect 👉 리다이렉트시 요청 메서드와 본문이 유지됨
- 기타 리다이렉션 캐시를 활용할 것인지에 대한 여부
  - 304 Not Modified 👉 리소스가 수정되지 않았다는 뜻
    - 캐시 목적으로 사용. 클라이언트가 캐시된 데이터를 조회하도록 유도
    - 응답에 바디가 있으면 안 됨

💡PRG(Post, Redirect, Get) 패턴 : 게시글 작성(Post) → 응답(Redirect) → 리다이렉트 요청(Get)

PRG 패턴 미적용시 👉 새로고침을 하게되면 요청이 중복으로 처리됨
PRG 패턴 적용시 👉 새로고침을 하게되면 GET 요청을 함

4xx (클라이언트 에러)
- 클라이언트측 오류, 잘못된 문법 등으로 서버가 요청 수행 불가능
- 클라이언트의 요청이 잘못되었기 때문에, 같은 요청의 재시도는 실패
- 400 Bad Request
  - 클라이언트가 HTTP 요청 내용을 수정 후 보내야 함
    ex) GET 메소드 API인데 POST로 보낼때, API 스펙 불일치, 숫자를 문자로, 문자를 숫자로 등
- 401 Unauthorized
  - 클라이언트가 리소스에 대한 인증(Authentication) 이 필요
  - 응답에 WWW-Authenticate 헤더와 함께 인증 방법을 설명 ex) 로그인
- 403 Forbidden
  - 서버가 요청을 받았지만 승인 거부, 주로 인가(Authorization) 관련문제
    ex) 일반 유저, 관리자
- 404 Not Found
  - 요청한 리소스가 서버에 없음 👉 이를 이용하여 리소스를 숨김. 있지만 없는척 가능

5xx (서버 에러)
- 서버 오류, 요청은 정상이지만 서버가 처리하지 못함 👉 재시도하면 성공 가능
  ex) 서버가 일정시간 다운되었다가 다시 살아난 경우
- 실제 서버에서 문제가 발생한 경우 5xx Error이기 때문에 발생하지 않는것이 최선
- 500 Internal Server Error 대부분 500으로 처리함
- 503 Service Unavailable 서비스 이용 불가
  - Retry-After Header 사용시 복구 소요시간 응답 가능

6. HTTP API 설계

📌 요구사항 : 게시글 관리 HTTP API 설계

💡 HTTP API 설계 - 잘못된 예시
   - 게시글 생성  👉  /create/board
   - 게시글 1개 조회  👉  /read/board/1
   - 게시글 목록 조회  👉  /read/board-list
   - 게시글 수정  👉  /update/board/1
   - 게시글 삭제  👉  /delete/board/1

📌 HTTP API 설계 규칙

HTTP API 설계시 항상 리소스 식별 기준 리소스 : 게시글
URI에 들어갈 리소스는 단수 형태가 아닌 복수 형태 사용 권장 board → boards
URL에 동사 사용금지 / HTTP Method의 역할 URL에 포함금지

📌 HTTP API 설계

성공시 상태코드 : 2xx
실패시 상태코드 : 4xx (클라이언트 문제) OR 5xx (서버 문제)
- 게시글 생성 👉 POST , /boards
- 게시글 1개 조회 👉 GET , /boards/{id}
- 게시글 목록 조회 👉 GET , /boards
- 게시글 수정 👉 PUT or PATCH , /boards/{id}
- 게시글 삭제 👉 DELETE , /boards/{id}

7. HTTP Header

📚 클라이언트와 서버가 요청 또는 응답으로 부가적인 정보
(Message Body 내용, 크기, 인증, 브라우저 정보, 서버 정보 등)를 전송 가능 하도록 함

Header 구조
- field-name : OWS field-value OWS (OWS : 띄어쓰기 허용) , 대소문자 구분 X
- HTTP 전송에 필요한 모든 부가정보 표현 가능
- 서버가 값을 알고 있는 경우 임의의 Header 추가 가능
- 텍스트 (plain text)로 이루어짐
- 각각의 헤더는 하나의 줄로 구분

💡 실제 HTTP Header 확인법
개발자도구(F12) → Network 탭 클릭 → Fetch/XHR 탭 클릭 → 우측 Header 정보

8. 대표적인 HTTP Header

💡 참고자료 : 표준 HTTP 헤더

Ⅰ. 표현 헤더(Representation)

실제 데이터 전송시 특정 형식으로 변환하여 전송
리소스에 대한 표현 정보(어떤 데이터 형식으로 보낼지)를 나타냄
요청, 응답에 모두 사용되는 Header

📌 표현 헤더의 종류

Content-Type : 형식
- 전송할 데이터의 미디어 타입, 문자 인코딩
- text/html; charset=utf-8 application/json
Content-Encoding : 압축 방식
- 데이터 압축 후 Encoding 헤더를 추가하면, 읽는 쪽에서 해당 정보로 압축을 해제
- gzip
- identity : 압축하지 않음
Content-Language : 언어
- 데이터의 언어를 표현 ex) ko는 한글 출력, en은 영어 출력
Content-Length : 길이
- 실제로는 표현 헤더가 아닌, 페이로드(Payload) 헤더, byte 단위

Ⅱ. 컨텐츠 협상(Content Negotiation)

📚 클라이언트가 선호하는 표현을 요청 / 요청시에만 사용되는 Header

우선순위 존재
- Quality Values 줄여서 q 값을 사용
- 0 ~ 1 사이의 값이 존재하며 1에 가까울수록 우선순위 높음
- Value가 1인 경우 생략 가능
  ex) Accept-Language: ko-KR,en-US;q=0.9,en;q=0.8
  → 서버에서 지원 가능시 우선순위 기반으로 응답 데이터 표현
- q가 생략되었다면 선언된 순서대로 우선순위를 가짐
  Accept: application/json, text/plain, */* → application/json ⇒ text/plain ⇒ */*
- 구체적으로 선언된 것이 우선순위 높음
  Accpet: text/*, text/plain, text/plain;format=flowed, */*
  → text/plain;format=flowed ⇒ text/plain ⇒ text/* ⇒ */*

📌 컨텐츠 협상헤더의 종류

Accept : 선호하는 미디어 타입
Accept-Charset : 선호하는 문자 인코딩
Accept-Encoding : 선호하는 압축 인코딩
Accept-Language : 선호하는 언어

Ⅲ. 일반 정보

📚 단순한 정보들을 나타내는 Header

📌 일반 정보 헤더의 종류

From : 클라이언트 이메일 정보 잘 사용하지 않음
Referer : 현재 요청된 페이지의 이전 웹 페이지 주소 → 유입 경로 파악 가능요청시 사용
User-Agent : 클라이언트 애플리케이션 정보(PC, Mobile 브라우저) 요청시 사용
- 어떤 환경에서 주로 접속하는지 통계
- 어떤 종류의 환경에서 장애가 발생하는지 파악 가능
Server : 요청을 처리하는 ORIGIN 서버의 Software 정보 응답시 사용
Date : HTTP 요청이 발생한 날짜와 시간 응답시 사용

Ⅳ. 특별 정보

📌 특별 정보 헤더의 종류

Host : 요청한 도메인 정보 필수포함 요청시 사용
Location : 생성된 리소스 URI 응답코드 3xx , 리다이렉트 주소 응답코드 201(Created)
Allow : 허용 가능한 HTTP Method 응답코드 405 (Method Not Allowed)
ex) Allow: GET, POST
Retry-After : 다음 요청까지 대기 해야하는 시간 응답코드 503 (Service Unavailable)

Ⅴ. 인증

📌 인증 헤더의 종류

Authorization : 클라이언트 인증 정보
- 선택한 인증 방법에 따라 Value 작성
WWW-Authenticate : 리소스에 필요한 인증 방법 응답코드 401 (Unauthorized)

Ⅵ. Cookie

HTTP는 Stateless 특성이 있어 상태를 매번 전송해야 함 → Cookie로 모든 요청마다 상태 전달
사용자 세션 관리, 광고 정보 트래킹에 많이 사용

📌 쿠키의 종류

Set-Cookie : 서버에서 응답시 클라이언트로 Cookie 값 전달
- 만료기간(expire, max-age), 사용될 위치(domain, path) 설정 가능
- 주의 항상 서버에 전달되니 최소한의 정보만 사용하여 트래픽을 최적화 해야 함
- 주의 탈취 당하기 쉬우니 보안에 민감한 개인정보 등은 저장 금지
Cookie : 클라이언트가 서버에서 받은 쿠키를 Cookie 헤더를 통해 전송
Secure : 해당 헤더가 적용되면 https인 경우에만 쿠키를 전송 HTTP + Secure = HTTPS
👉 기본적으로 http, https 구분하지 않고 쿠키를 전송
HttpOnly : http 전송에만 사용, 자바스크립트에서 쿠키를 접근하지 못하게 만듦
SameSite : 쿠키에 설정된 도메인이 같은 경우만 쿠키를 전송

Ⅶ. Cache

캐시가 없다면 같은 요청에 대한 응답 데이터가 같아도 매번 데이터를 새로 다운로드 받게 됨
새로 다운로드 받으면 속도 하락 및 비용 발생

📌 캐시의 종류

Cache-Control : 응답시 사용 max-age
👉 캐시 유효 시간(초) : 유효 시간 초과시 다시 서버를 통해 데이터를 응답받고 캐시를 갱신
Cache-Control: no-cache 👉 캐시 가능한 데이터지만, 서버에 검증하고 사용
Cache-Control: no-store 👉 보안에 민감한 데이터, 캐시하지 않음
if-modified-since : 캐시로 저장된 데이터 최종 수정일 요청시 사용
Last-Modified : 데이터가 마지막으로 수정된 시간 응답시 사용
- if-modified-since 요청시 응답
- 304 (Not Modified) 상태코드와 함께 응답시 : 수정되지 않음
  - HTTP Message Body가 존재하지 않음. 캐시 사용
ETag : 캐시용 데이터에 날짜, 시간이 아닌 이름을 지정 요청시 사용
- if-modified-since + Last-Modified 방식은 수정된 데이터가 같거나 캐시가 불필요한 경우를 구분 못함

8. Restful API

📚 REST를 잘 준수하는 API로 HTTP 프로토콜을 사용하여 클라이언트와 서버 간의 통신을 통해 리소스를 관리함. 리소스는 고유한 URI로 식별되며, HTTP 메서드를 통해 다양한 작업을 수행하며 요청과 응답은 일반적으로 JSON 또는 XML 형식으로 이루어짐
👉 REST 기반으로 서비스 API를 구현한 것, HTTP API를 잘 설계하는 규칙

💡 REST(Representational State Transfer)

자원(Resource)을 이름(Name)으로 구분하여 해당 자원의 상태(정보)를 주고받는 것
URI를 통해 자원(Resource)을 명시하고, HTTP Method(POST, GET, PUT, DELETE,PATCH 등)를 통해 해당 자원에 대한 CRUD Operation을 적용하는 것

규칙
1. 리소스는 명사, 소문자, 복수 형태를 사용해야 함
2. REST만으로 해결하기 어려운 경우 동사 허용
3. 자원의 계층 관계를 슬래시/로 표현
4. 마지막 문자에는 슬래시/ 사용 금지
5. 언더바_가 아닌 하이픈-을 사용
6. URI에 파일 확장자 포함 금지
7. CRUD 함수명은 사용하지 않고, HTTP Method를 활용
8. 정렬, 필터링, 페이징은 신규 API를 만드는것이 아닌 Query Parameter를 사용

📌 Maturity Model (성숙도 모델) → REST의 제약 조건에 따라 API를 등급화하는 방법

💡 참고자료1 / 참고자료2 / 참고자료3

Level0

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

요청 예시 모든 요청이 단일 URI로 전송

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

Level1
- 외부로 공개하려는 리소스에 대해서 의미있는 URL로 표현하기 시작한 단계
- 적절한 패턴이 있지만 HTTP의 메소드 별로 서비스를 구분하여 사용하지는 않음
  → 서비스 형태나 작업의 종류에 맞추어 적절한 HTTP 메소드를 지정하지 않음
- 사용자의 요청을 GET, POST로 대부분 처리하고 에러를 반환
- 요청 예시 리소스에 대해 분리된 엔드포인트 보유
```
POST /users
{
    "name": "sparta",
    "password": "codingclub"
}
```
Level2
- 리소스를 적절한 용도와 상태에 따라 HTTP Methods에 맞게 설계하고 서비스하는 단계
- RESTful Service의 DB에 저장된 리소스를 확인 및 데이터 조작을 위해 CRUD와 매칭되는 HTTP Methods를 이용하여 서비스 하는 것
- 읽기 : GET 새로운 리소스 추가 : POST 기존 리소스 상태 변경 : PUT, PATCH 삭제 : Delete
- HTTP Method로 리소스의 상태를 구분하여 서비스 하면 비슷한 이름의 URI도 HTTP Method에 따라 다른 형태의 서비스 제공 가능
- 요청 예시 HTTP Method 활용
```
GET /users/123     // 특정 사용자 조회
```
```
POST /users        // 사용자 생성
{
    "name": "sparta",
    "password": "codingclub"
}
```
```
PUT /users/123     // 사용자 정보 수정
{
    "name": "java",
    "password": "spring"
}
```
```
DELETE /users/123  // 사용자 삭제
```
Level3
- 데이터를 가지고 그 다음 작업에서 가능한 작업이 무엇인지 상태 정보와 함께 넘겨줌
- 클라이언트 측에서는 서버가 제공하는 서비스를 일일이 찾는 수고가 사라짐
- 엔드포인트만 가지고 있으면 서버가 제공할 수 있는 다음, 그 다음 URI값을 알게됨
- 요청 예시 응답 내에 링크 포함
```
GET /users/123
{
    "id": 123,
    "name": "sparta",
    "links": {
        "self": "/users/123",
        "update": "/users/123",
        "delete": "/users/123"
    }
}
```

💡 HATEOAS(Hypermedia As The Engine Of Application State)

회원가입 후 회원정보 수정방법, 조회방법, 
회원조회를 하면서 그다음 단계로 진행할 수 있는 또 다른 리소스에 대한 정보를 같이 알려주는 기능

📌 RESTful API 설계 시 고려사항

1. Consumer first

개발자 중심의 설계방식보다 해당 API의 소비자 입장에서 간단하고 직관적인 API를 설계 해야함
소비자 : 엔드유저가 아닌 API를 사용 중인 또다른 시스템, 개발자 등

2. Make best use of HTTP

HTTP Method와 Request, Response, Header와 같은 HTTP의 장점을 살려서 개발

3. Request methods

최소한 성숙도 모델 Level2를 사용

4. Response Status

각각의 API 요청에 따라서 적절한 HTTP 상태코드 전달
성공했다, 실패했다가 아닌 실패와 성공에 대한 이유를 함께 반환

5. No secure info in URI

URI에 사용자 정보 포함 금지

6. Use plurals

제공하는 데이터에 대하여 단수가 아닌 복수형태로 쓰는것이 일반적 ex) /user -> /users
특정 유저를 찾으려면 엔드포인트에 값을 추가 ex) /users/1

7. User nouns for resources

모든 리소스는 가능하면 동사가 아닌 명사형태로 표시
API URI만 보고도 어떠한 API인지 파악 가능하도록 권장

8. For exceptions - define a consistent approach

일괄적인 엔드포인트 사용 권장

destro

<포르투갈어> 솜씨 있는. 재간 있는. 능란한. 기민한. (재주가) 비상한.