[TIL] 🌐HTTP (Hyper Text Transfer Protocol)

🌐HTTP (Hyper Text Transfer Protocol)

HTTP 동작 방식

• 클라이언트: 서버에 자원을 요청(Request)
• 서버: 요청을 처리 후 결과를 응답(Response)
  
  

주요 특징

📌 서버-클라이언트 구조

• 서버와 클라이언트는 서로 독립적으로 동작
• 서버는 여러 클라이언트의 요청을 동시에 처리할 수 있으며, 클라이언트는 서버로부터 받은 데이터를 통해 화면을 구성
  
  

📌 비연결(Connection-less)
: 클라이언트와 서버는 요청-응답 후 연결을 유지하지 않음. 매 요청마다 새로운 연결 설정 필요.

• 서버는 연결 설정에 필요한 자원 소모 해결
• 요청마다 연결 설정(3-way Handshaking) 해야하므로 응답 시간 증가
• 캐시, 브라우저 캐싱로 해결
• 현재는 HTTP 지속연결(Persistent Connections) 으로 해결
  • 하나의 요청에 필요한 요청들이 모두 응답될 때 까지 연결을 유지
    
    

📌 무상태(State-less)
: 서버는 이전 요청의 상태를 기억하지 않음

• Cookie, Session, Token 등을 활용하여 보완
  
  
  

HTTP 메소드

• POST : 리소스 생성
  - Message Body를 통해 요청 데이터를 전달
  
  
• GET : 리소스 조회
  - 쿼리 스트링 포함 O / X 경우
  
  
• PUT : 리소스 덮어쓰기
  - POST와는 다르게 클라이언트 측에서 리소스를 식별하여 URI를 지정
  - 기존 리소스 존재하는 경우: 전체 수정 (대체된 리소스)
  - 기존 리소스 존재, 일부 수정하는 경우: 덮어쓰기 (대체된 리소스)
  - 기존 리소스 X : 새로 생성
  
  
• PATCH : 리소스 부분 수정 (부분 수정된 리소스)
• DELETE : 리소스 삭제
  
  

💡 PUT vs PATCH

PUT: 전체 수정 (리소스를 완전히 덮어씀)

PATCH: 부분 수정 (일부 필드만 변경)

HTTP 메소드의 속성

1. 안전성(Safe)
- 안전: GET (조회)
- 안전X: POST, PUT, DELETE, PATCH —> 데이터 수정/삭제가 일어나는 요청

2. 멱등성(Idempotent)

• 같은 연산 여러번 해도 결과 변하지않음
  - POST: 멱등성 보장X
  - GET, PUT, DELETE: 멱등성 O
  
  
• 사용자의 실수로 인한 중복 요청을 막기 위한 방법
  - 의도적인 동일 요청을 방지하는 방법은 아님 (ex. A에서 B로 리다이렉트 되었으나 다시 A로 돌아가 요청 보냄)
  - 이 경우 토큰 사용, 서버에서 동일 요청 제출 차단 등의 추가적인 조치가 필요
  
  
• 재요청 중에 리소스 변경되는 건 멱등성 위반으로 고려 X
  
  
• 요청이 실패한 경우 재시도 하기위해 필요하다.
  1. 항상 결과가 같다면 마음껏 재시도 해도된다.
  2. 만약 멱등하지 않다면, 중복 요청을 보내서는 안된다.
  3. 멱등성은 복구 매커니즘에 사용한다.
  • ex) 요청 실패시 서버에서 자동으로 재시도하도록 처리
    
    

3. 캐시가능성(Cacheable)

• 재사용을 위해 요청에 대한 응답을 저장해도 되는가?
• 가능: GET, HEAD, POST
  - 주로 GET, HEAD 정도만 캐시로 사용
  - 정적 자원(HTML, CSS …) 위주로 캐싱
  
  
  

HTTP 상태 코드

: 요청에 대한 처리 결과를 응답하는 코드. 데이터와 함께 반환된다.

🔹 클라이언트가 인식하지 못하는 상태 코드를 서버가 반환해도, 클라이언트는 상위 상태 코드(1xx, 2xx 등)로 해석하여 처리
🔹 상위 상태 코드: 1xx, 2xx, 3xx, 4xx, 5xx

• 1xx : 정보

  • 요청 수신 후 처리중인 상태, 잘 사용하지 않음
    
    

• 2xx : 성공

  • 200 OK
  • 201 Created
  • 202 Accepted : 요청 수신 완료, 처리는 완료X
  • 204 No Content : 요청 성공, 응답 데이터는 따로 없음.

• 3xx : 리다이렉션

• 4xx : 클라이언트 에러

  • 400 Bad Request : 잘못된 요청(ex. 요청 메소드, 파라미터 값이 API 스펙과 맞지 않음)
  • 401 Unauthorized : 인증 필요
  • 403 Forbidden : 요청 받았지만 승인 거부 (주로 인가 authorized 문제)
  • 404 Not Found : 요청한 리소스가 서버에 없음 (혹은 없는척)

• 5xx : 서버 에러
  - 500 Internal Server Error : 서버 내부 문제, 주로 이거 사용
  - 503 Service Unavailable : 서비스 이용 불가
  
  
  

PRG 패턴(Post/Redirect/Get)

: 사용자가 POST 요청을 보낸 후, 곧바로 GET 요청으로 리다이렉트하는 방식
👉 POST ➡️ Redirect(3xx) ➡️ GET

• Post 요청에 대한 응답이 또 다른 URL로의 GET 요청을 위한 리다이렉트(응답 코드가 3XX)여야 한다는 것
  
  

필요성

✅ 멱등성 보장

• POST 요청은 멱등성이 없으므로 새로고침 등으로 여러 번 실행 시 중복 데이터 생성 가능
• 리다이렉트 후 GET 요청을 수행하면 데이터 수정 없이 안전한 요청이 가능

✅ 중복 요청 방지

• POST 요청 후 사용자가 새로고침 시 동일한 요청(POST) 반복될 수 있음
• PRG 패턴 적용 후, 새로고침을 해도 GET 요청만 하므로 데이터 중복 생성되는 문제 방지
  
  
  
  

🍪쿠키&캐시

: HTTP는 무상태(Stateless) 특성을 가지므로, 서버는 기본적으로 클라이언트의 상태(로그인 정보, 방문 기록 등)를 기억하지 않음
➡️ 이를 보완하기 위해 쿠키와 캐시를 활용

쿠키

: 클라이언트(브라우저)에 저장되는 작은 데이터로, 클라이언트는 쿠키를 사용하여 모든 요청마다 상태를 함께 전달한다.

✔️ 주로 사용자 인증(로그인 정보), 세션 유지, 개인화된 설정 저장 등에 사용

캐시

: 서버로 받은 데이터 중 자주 사용하는 데이터를 저장해두어 빠르게 사용할 수 있도록 하는 기능.

✔️ 정적 자원(HTML, CSS, JS 등)을 저장하여 페이지 로딩 속도 향상
✔️ 서버 응답을 캐시로 저장하여 서버의 부하를 감소시킴