[내일배움캠프 Spring_3기] HTTP

HTTP(HyperText Transfer Protocol)

HTTP란?

• 웹에서 데이터를 주고받기 위한 통신 규약
• 편지를 주고받는 것과 비슷하게, 보내는 사람, 받는 사람, 내용이 정해진 형식으로 전달됨

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

HTTP 특징

무상태

• 서버는 클라이언트의 상태를 보존하지 않음

장점

• Scale Out 수평 확장성이 높음
• 갑자기 요청량이 증가하여도 서버를 증설 하기 쉬움

단점

• 클라이언트가 데이터를 추가적으로 전송해야 함

한계점
무상태로 설계할 수 없는 경우가 있음
로그인은 어떻게 해야할까? -> Cookie, Session, Token 등을 활용

---

HTTP Message 구조

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

HTTP Message 구조

---

HTTP 요청 메시지(Request Message)

1. Start Line

• HTTP Method

  • Get
  • 요청의 의도를 가진 GET, POST, PUT, PATCH, DELETE 등이 있음
    • Create - POST
    • Read - GET
    • Update - PUT(전체), PATCH(일부)
    • Delete - DELETE
    • Request Target

• path

  • 경로: /event
  • Query String(= Query Parameter)에 해당하는 값도 포함

• HTTP Version

  • 1.1

2. Header

   • Host: spartacodingclub.kr
   • 임의의 Header를 추가할 수 있음 (단, 서버가 값을 알고 있어야 함)
   • 요청의 추가 정보들을 가지고 있다.

   ex) Message Body 내용, 크기, 인증, 브라우저 정보, 서버 정보 등

3. Empty Line

   • 공백 한 줄
   • 필수 값

4. Message Body

   • 실제 전송하는 데이터가 담겨 있는 부분
     • HTML, 이미지, JSON 등 byte로 표현되는 모든 데이터 전송 가능.
   • 요청 시 GET의 경우 Message Body가 지원되지 않는 경우가 많다.
     

---

HTTP 응답 메시지(Response Message)

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

---

HTTP Method

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

주요 Method

1. POST

• 리소스 생성
• 다른 Method로 처리하기 애매할 때 POST를 쓰기도 함
• Message Body를 통해 요청 데이터를 전달

2. GET

• 리소스 조희
• Message Body가 없음

3. PUT

• 리소스 덮어쓰기

4. PATCH

• 리소스 부분 수정

5. DELETE

• 리소스 삭제

6. 기타 Method

• HEAD: GET에서 Message Body를 제외하고 상태 줄과 Header만 반환
• OPTIONS: 대상 리소스에 대한 통신 가능한 Method를 설명함

---

HTTP Method 속성

안정성(Safe)

• GET 메소드(조회)는 안전하다.
  • 저장된 데이터를 변환하지 않는다.
• POST, DELETE, PUT, PATCH는 안전하지 않다.
  • 데이터를 생성, 수정, 삭제한다.

멱등성(Idempotent)

• 한번을 호출하거나 수천번을 호출하거나 항상 결과는 같다.
  1. GET → 같은 결과가 계속 조회된다.
  2. PUT → 수정해서 대체된 후의 결과는 계속 같다.
  3. DELETE → 같은 요청을 여러번해도 삭제된 결과는 같다.
  4. POST → 멱등성을 보장하지 않는다.
• 요청이 실패한 경우 재시도 하기 위해 필요하다.

  1. 항상 결과가 같다면 마음껏 재시도 해도 된다.

  2. 만약 멱등하지 않다면, 중복 요청을 보내서는 안된다.

  3. 복구 매커니즘에 사용한다.

     ex) 요청 실패시 서버에서 자동으로 재시도

캐시가능성(Cacheable)

• 재사용을 위해 요청에 대한 응답을 저장할 수 있는가?

  1. GET, HEAD, POST 메소드는 캐시가 가능하다.

  2. 일반적으로 GET, HEAD 정도만 캐시로 사용한다.

     ex) 변경 가능성이 적은 정적자원(HTML, CSS, IMAGE, JS 등)을 주로 캐싱한다.

---

HTTP 상태 코드

• 1xx (정보)

  • 요청 수신 후 처리중인 상태
  • 잘 사용하지 않는다.

• 2xx (성공)

  • 정상 처리 완료된 상태

    

  • 대표 상태코드

    • 200 OK

      • 요청 성공

    • 201 Created

      • 새로운 리소스 생성

    • 202 Accepted

      • 요청이 수신되었으나 데이터 처리가 완료되지 않음

      • 주로 Batch 처리에서 사용된다.

        ex) 설정한 시간마다 반복적으로 동작하는 특정 작업.

    • 204 No Content

      • 요청은 성공했지만, 응답 데이터가 없음

        ex) 삭제 성공 시

• 3xx (리다이렉션)

  • 요청을 완료하려면 추가 행동이 필요한 상태
  • 3xx 응답 + Location HTTP Header가 있으면 Location 위치로 리다이렉트 한다. ex) OAuth 구현 시 많이 볼 수 있음. (카카오 로그인, 구글 로그인 등)
    

• 4xx (클라이언트 에러)

  • 클라이언트측 오류, 잘못된 문법 등으로 서버가 요청을 수행할 수 없다.

  • 클라이언트의 요청이 잘못되었기 때문에, 같은 요청의 재시도는 실패한다.

    

  • 대표 상태코드

    • 400 Bad Request

      • 클라이언트가 HTTP 요청 내용을 수정 후 보내야 한다.

        ex) GET 메소드로 만들어진 API인데 POST로 보낸다?

        ex) 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를 사용하면 얼마뒤에 복구되는지 응답할 수 있다.