TIL 2024-10-31 (Spring 입문 - HTTP)

1 ) HTTP 

 

1. 동작 순서

• 클라이언트는 Request(요청)을 보내고, 응답을 기다린다.
• 서버는 요청에 대한 처리를 수행 후 결과를 Response(응답)한다.

 

    2. Message 구조

• Start Line 
  • 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)에 해당되는 값도 포함된다.
  • HTTP Version
    • 1.1
    • HTTP Version을 나타낸다.
• Header
  • Host : ... 를 가진다.
  • field-name : OWS field-value OWS (OWS : 띄어쓰기 허용) 구조를 가진다
  • 대소문자 구분 하지 않는다.
  • 임의의 Header를 추가할 수 있다.
  • 요청의 추가 정보들을 가지고 있다.
• Empty Line
  • 공백 한 줄
  • 필수 값
• Message Body
  • 실제 전송하는 데이터가 담겨 있는 부분
    • HTML, JSON, 이미지 등 byte로 표현되는 모든 데이터 전송 가능.
  • 요청 시 GET의 경우 Message Body가 지원되지 않는 경우가 많아 권장하지 않는다.

 

 

• 주요 Method
  • POST
    • 리소스 생성
    • 주소 HTML FORM (회원가입, 게시글 작성 등) 사용
    • 요청 데이터를 처리하는 방식에 정해진 것은 없다.
      1. 요청 데이터 처리(로그인 등)에 사용된다.
      2. 조회 시 JSON 요청 데이터가 필요한 경우에도 사용될 수 있다.
    • Message Body를 통해 요청 데이터를 전달한다.
  • GET
    • 리소스 조회
    • Query String 미포함하는 경우
      • GET의 경우 Message Body가 지원되지 않는 경우가 많아 권장하지 않음.
    • Query String 포함하는 경우
      • 서버에 추가적인 데이터 전송을 해야한다면, Message Body가 아닌 Query String을 사용.
  • PUT
    • 리소스 덮어쓰기
    • POST와는 다르게 클라이언트 측에서 리소스를 식별하여 URI를 지정.
      1. 기존의 리소스가 존재하는 경우 - 리소스 전체 수정
      2. 기존 리소스가 존재하고 일부만 변경하는 경우 - 기존 리소스가 존재하면 완전히 덮어쓰기가 된다
      3. 기존 리소스가 없는 경우 - 리소스가 없으면 생성된다.
  • PATCH
    • 리소스 부분 수정
  • DELETE
    • 리소스 삭제

 

---

2 ) HTTP_2

• Method 속성

 

1. 안정성 (Safe)
   • Get 메소드(조회)는 안전하다.
     • 저장된 데이터를 변환하지 않는다.
   • POST, DELETE, PUT, PATCH는 안전하지 않다.
     1. 데이터를 생성, 수정, 삭제한다.
2. 멱등성 (Idempotent)
   • 한번을 호출하거나 수천번을 호출하거나 항상 결과는 같다.
     1. GET -> 같은 결과가 계속 조회된다.
     2. PUT -> 수정해서 대체된 후의 결과는 계속 같다.
     3. DELETE -> 같은 요철을 여러번해도 삭제된 결과는 같다.
     4. POST -> 멱등성을 보장하지 않는다.
   • 요청이 실패한 경우 재시도 하기위해 필요하다.
     1. 항상 결과가 같다면 마음껏 재시도 해도된다.
     2. 만약 멱등하지 않다면, 중복 요철을 보내서는 안된다.
     3. 복구 매커니즘에 사용한다.
3. 캐시 가능성 (Cacheable)
   • 재사용을 위해 요청에 대한 응답을 저장할 수 있는가?
     1. GET, HEAD, POST 메소드는 캐시가 가능하다.
     2. 일반적으로 GET, HEAD 정도만 캐시로 사용.

캐시(Cache)란?

• 클라이언트가 서버에  한번 요청했던 데이터에 대해서 매번 요청할 때 마다 다시 전송할 필요가 없도록 웹 브라우저가 임시적으로 데이터를 보관하고 있는 장소.

 

---

 

3 ) HTTP Status Code

• 1XX(정보)
  • 요청 수신 후 처리중인 상태
  • 잘 사용하지 않음
• 2XX(성공)
  • 200 OK
    • 요청 성공
  • 201 Created
    • 새로운 리소스 생성
  • 202 Accepted
    • 요청이 수신되었으나 처리가 완료되지 않음.
    • 주로 Batch 처리에서 사용된다.
  • 204 No Content
    • 요청은 성공했지만, 응답 데이터가 없음.
• 3XX (리다이렉션)
• 4XX (클라이언트 에러)
  • 400 Bad Request
    • 클라이언트가 HTTP 요청 내용을 수정 후 보내야한다.
    • API 스펙과 일치하지 않을 때
  • 401 Unauthorized
    • 클라이언트가 리소스에 대한 인증(Authentication)이 필요하다
    • 응답에 WWW-Authenticate 헤더와 함께 인증 방법을 설명한다.
  • 403 Forbidden
    • 서버가 요청을 받았지만 승인 거부
    • 주로 인가(Authorization) 관련 문제
  • 404 Not Found
    • 요청한 리소스가 서버에 없다.
    • 이를 이용하여 리소스를 숨겨놓기도 한다. 있지만 없는 척 가능.
• 5XX (서버 에러)
  • 500
    • 대부분 500으로 처리.
  • 503
    • 서비스 이용불가
• 다 외울 필요는 없고 100단위 마다 어떤 상태를 의미하는 지만 알고 있으면 된다!!