Spring 입문 (HTTP)

HTTP의 특징: Stateless

서버는 클라이언트의 상태를 보존하지 않고, 모든 요청을 독립적으로 처리한다.

• 장점: 수평 확장성이 높다.
  • 서버는 사용자를 추적하지 않고 요청 내용만 보고 응답한다.
  • 클라이언트는 어느 서버에 요청을 하든 똑같은 결과를 얻을 수 있다.
• Stateful 요소가 필요한 경우가 있다.
  • 예: 로그인
  • 이런 경우 쿠키, 세션, 토큰 등을 활용하여 State를 구현한다. 세부 내용은 추후에 다루자.

HTTP 메시지 구조

여기서는 HTTP/1.1을 다룬다
공식 문서: https://datatracker.ietf.org/doc/html/rfc7230#section-3

A. 요청 메시지

• Start Line: method SP request-target SP HTTP-version CRLF (SP는 single space, CRLF는 \r\n)

  • method: 요청 종류

    • Create: POST
    • Read: GET
    • Update: PUT(덮어쓰기-전체 교체), PATCH(부분 수정)
    • Delete: DELETE
    • 기타: HEAD(본문 제외 상태 라인 및 헤더만 요청), OPTIONS(사전 요청-통신 가능한 Method 확인 요청)
      • 분류가 애매한 요청은 POST를 많이 쓴다. (예: 로그인 요청)

  • request-target: 요청을 보내는 대상 주소/경로

    • 예: /index.html

  • HTTP-version
    - 1.1의 경우 HTTP/1.1

• Header: key-value 데이터

  • 호스트 정보, 브라우저 정보, 메시지 바디 크기 등 요청의 추가 정보

• Empty Line: CRLF

• Message Body: 실제 전송하는 데이터. 모든 바이트 데이터 전송 가능(HTML, 이미지, ...)

  • 없을 수도 있음 (예: GET 요청에 대해선 Message Body가 지원되지 않는 경우가 많다.)

B. 응답 메시지

• Start Line: HTTP-version SP status-code SP reason-phrase CRLF (예: HTTP/1.1 200 OK)

  • status-code: 3-digit 정수 코드
    • 예: 200, 404
    • 클라이언트는 상태 코드를 기반으로 나머지 응답을 해석
  • reason-phrase: 간단한 설명용 텍스트
    • 예: OK, Not Found

• Header: Response에서만 사용되는 Header 값들이 따로 존재한다.

HTTP Method 속성

1. 안정성(Safe)

메서드를 실행했을 때 데이터가 안전한가?

• GET(조회): 데이터를 변환하지 않으니 안전하다.
• POST, DELETE, PUT, PATCH: 안전하지 않다.
  • 데이터를 생성, 수정, 삭제하므로

2. 멱등성(Idempotent)

몇 번을 호출해도 결과가 항상 같은가?

• GET: 몇 번을 조회해도 결과는 같다.
• PUT: 몇 번을 덮어써도 결과는 같다.
• DELETE: 같은 요청을 여러 번 해도 삭제된 결과는 같다.
• POST: 요청한 횟수만큼 데이터가 생성된다. -> 멱등성을 보장하지 않는다.
• PATCH의 경우 HTTP 스펙 상 구현 방법에 제한이 없어 구현에 따라 멱등할 수도, 그렇지 않을 수도 있다.

서버 복구 매커니즘에 사용된다.

• 멱등성이 보장된 메서드는, 요청 실패 시 중복 요청을 보내도 된다.
• 멱등하지 않다면, 함부로 중복 요청을 보내면 안된다.

3. 캐시가능성(Cacheable)

요청에 대한 응답을 저장해두고, 동일한 요청에 대해 곧바로 제공할 수 있는가?

• 이론적으로는 GET, HEAD, POST, PATCH 메서드는 캐시가능하다.
• 실무에서는 GET, HEAD 정도만 사용한다.
• POST나 PATCH는 서버 상태에 변경을 가하므로 캐시와 원본 데이터의 불일치 문제가 생길 수 있다.

HTTP 상태 코드

전부 외우기보단, 100단위로 어떤 의미인지만 파악해두자.

• 1xx(정보)
  • 요청 수신 후 처리중인 상태
• 2xx(성공)
  • 200 OK
    • 요청이 올바르게 처리됨
    • GET, PUT
  • 201 Created
    • 새로운 리소스 생성
    • POST, PUT(생성)
  • 202 Accepted
    • 요청은 수신되었으나, 데이터 처리 미완료
    • Batch 처리 등
  • 204 No Content
    • 요청은 성공했으나, 응답 데이터 없음
    • DELETE, PUT(덮어쓰기)
• 3xx(리다이렉션)
  • 요청을 완료하려면 추가 행동 필요
  • 3xx 응답 + Location HTTP Header -> Location 위치로 리다이렉트
  • OAuth 구현에서 많이 등장 (카카오 로그인, 구글 로그인 등)
• 4xx(클라이언트 에러): 클라이언트 문제이므로 똑같이 재시도 해도 실패
  • 400 Bad Request
    • 요청 자체가 잘못됨
  • 401 Unauthorized
    • 리소스에 대한 인증(Authentication) 필요: "너 누구야?"
    • 응답에 인증 방법 설명
    • 예: 로그인
  • 403 Forbidden
    • 요청을 받았지만 승인 거부
    • 인가(Authorization) 관련 문제: "네 권한 밖의 일이야."
    • 예: 일반 유저/관리자
  • 404 Not Found
    • 요청한 리소스가 서버에 없음
• 5xx(서버 에러): 서버 문제이므로 재시도 하면 성공할 수 있음
  • 500 Internal Server Error
    • 보통 이걸로 처리함
  • 503 Service Unavailable
    • 서비스 이용 불가
    • Retry-After 헤더를 통해 복구될 시간을 응답할 수 있음