HTTP - "모든 개발자를 위한 HTTP 웹 기본 지식" 정리노트 - 2

❗️ HTTP

메세지에 모든 것을 전송

• HTML, TEXT
• IMAGE, 음성, 영상, 파일
• JSON, XML (API)
• 거의 모든 형태의 데이터 전송 가능
• 서버간 데이터 교환도 대부분 HTTP 사용
• 지금은 HTTP의 시대이다!

❗️ HTTP 역사

HTTP/0.9 (1991): GET 메서드 지원, HTTP 헤더 X
HTTP/1.0 (1996): 메서드, 헤더 추가
HTTP/1.1 (1997): 가장 많이 사용 (가장 중요)
HTTP/2 (2015) : 성능 개선
HTTP/3 (진행중) : TCP 대신 UDP 사용, 성능 개선

❗️ 기반 프로토콜

TCP: HTTP/1.1, HTTP/2
UDP: HTTP/3

❗️ HTTP 특징
클라이언트 서버 구조
무상태 프로토콜(Stateless), 비연결성
HTTP 메시지
단순함, 확장 가능

❗️ 클라이언트 서버 구조
Request-Response 구조
서버에 요청을 보내고, 응답을 대기
서버는 요청에 대한 결과를 만들어서 응답

❗️ 무상태 프로토콜
서버가 클라이언트의 상태를 보존하지 않음
장점: 서버의 높은 확장성
단점: 클라이언트가 추가 데이터를 전송해야 함

❗️ Stateful, Stateless 차이

1. Stateful(상태 유지)
   노트북 구매 상황 예시
   
   중간에 점원이 바뀐다면?
   
2. Stateless(무상태)
   
   중간에 점원이 바뀐다면?
   

• 정리
  
  Stateful은 항상 같은 서버가 유지 (중간에 서버가 장애가 나면 큰 문제)
  Stateless는 아무 서버나 호출해도 됨 (중간에 서버가 장애가 나면 다른 서버로 대체)
  -> 수평 확장에 유리하다(스케일 아웃)

❗️ Stateless의 실무 한계

❗️ 연결 유지 모델

❗️ 비연결 모델

❗️ 비연결성
HTTP는 기본이 연결을 유지하지 않는 모델
일반적으로 초 단위 이하의 빠른 속도로 응답
1시간동안 수천명이 서비스를 사용한다고 해도 실제 서버에서 동시에 처리하는 요청은 수십개 이하로 매우 작음

• 서버 자원을 매우 효율적으로 사용할 수 있음

❗️ 비연결성 한계와 극복
TCP/IP 연결을 새로 맺어야 함 - 3 Way Handshake 시간이 추가됨
웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 자바스크립트, css, 추가 이미지 등 수 많은 자원이 함께 다운로드
-> 지금은 HTTP 지속 연결(Persistent Connections)로 문제 해결

❗️ HTTP 초기(연결, 종료 낭비)

❗️ HTTP 지속 연결

HTTP/2, HTTP/3 에서는 더 많은 최적화

❗️ 스테이스리스
서버 개발자들이 가장 어려워하는 업무
같은 시간에 발생하는 대용량 트래픽 처리
-> ex) 선착순 이벤트, 명절 기차표, 수강신청 등

❗️ HTTP 메시지

• 예시
  

❗️ 시작 라인(start-line)

• request-line / status-line
• request-line(요청메시지) = method request-target HTTP-version
  • ex) GET /serach?q=hello&hl=ko HTTP/1.1
    • method(HTTP 메서드): GET
    • request-target(요청 대상): /search?~~=ko
    • HTTP-version(HTTP 버전): HTTP/1.1
• status-line(응답 메세지) = HTTP-version status-code reason-phrase
  • ex) HTTP/1.1 200 OK
    • HTTP-version(HTTP 버전): HTTP/1.1
    • status-code(HTTP 상태 코드): 200 (성공)
    • reason-phrase(이유 문구): OK (사람이 이해할 수 있는 짧은 상태 코드 설명 문구)

❗️ HTTP 헤더

HTTP 전송에 필요한 모든 부가정보
ex) 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트(브라우저) 정보, 서버 애플리케이션 정보, 캐시 관리 정보 등

❗️ HTTP 메세지 바디

실제 전송할 데이터
HTML 문서, 이미지, 영상, JSON 등등 byte로 표현할 수 있는 모든 데이터 전송 가능
HTTP는 단순하고 확장이 가능한 기술

예시: 회원 정보 관리 API

• 회원 목록 조회
  URI: /read-member-list
• 회원 조회
  URI: /read-member-by-id
• 회원 등록
  URI: /create-member
• 회원 수정
  URI: /update-member
• 회원 삭제
  URI: /delete-member

-> 이것은 좋은 URI 설계인가?

❗️ 중요한 것은 리소스 식별

리소스란

• 회원을 등록하고 수정하고 조회하는 것이 리소스가 아님
• ex) 미네랄을 캐라: 리소스 X, 미네랄: 리소스
• 회원이라는 개념 자체가 리소스
• 회원을 등록, 수정, 조회하는 것을 모두 배제하고 회원이라는 리소스만 식별하면 됨
  -> 회원 리소스를 URI에 매핑

URI 수정

• 회원 목록 조회
  URI: /members
• 회원 조회
  URI: /members/{id}
• 회원 등록
  URI: /members/{id}
• 회원 수정
  URI: /members/{id}
• 회원 삭제
  URI: /members/{id}

-> 위의 예시가 정석이라고 할 순 없지만 앞의 예시보다는 좋은 설계

❗️ 리소스와 행위를 분리하자!
URI는 리소스만 식별
리소스와 해당 리소스를 대상으로 하는 행위를 분리
리소스는 명사, 행위는 동사
그렇다면 행위(메서드)를 구분하는 방법은?
-> HTTP 메서드

❗️ HTTP 메서드 종류

GET: 리소스 조회
POST: 요청 데이터 처리, 주로 등록에 사용
PUT: 리소스를 대체, 해당 리소스가 없으면 생성
PATCH: 리소스 부분 변경
DELETE: 리소스 삭제

HEAD: GET과 동일하지만 메세지 부분을 제외하고 상태 줄과 헤더만 반환
OPTIONS: 대상 리소스에 대한 통신 가능 옵션(메서드)을 설명(주로 CORS에서 사용)
CONNECT: 대상 자원으로 식별되는 서버에 대한 터널을 설정
TRACE: 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행

❗️ GET

역할
리소스 조회
서버에 전달하고 싶은 데이터는 query를 통해서 전달
메세지 바디를 사용해서 데이터를 전달할 수 있지만, 지원하지 않는 곳이 많아 권장되진 않음

리소스 조회 순서
1. 메시지 전달

2. 서버 도착
3. 응답 데이터 전송

❗️ POST

역할

• 요청 데이터 처리
• 메세지 바디를 통해 서버로 요청 데이터 전달
• 서버는 요청 데이터를 처리
  • 메시지 바디를 통해 들어온 데이터를 처리하는 모든 기능 수행
• 주로 전달된 데이터로 신규 리소스 등록, 프로세스 처리에 사용

리소스 등록 순서
1. 메시지 전달
2. 신규 리소스 생성
3. 응답 데이터 전송(등록 성공/실패 등)

POST에 대하여
POST 메서드는 대상 리소스가 리소스의 고유한 의미 체계에 따라 요청에 포함된 표현을 처리하도록 요청
POST가 사용되는 기능 예시
-> 리소스 URI에 POST 요청이 오면 요청 데이터를 어떻게 처리할지 리소스마다 따로 정해야 함(미리 정해진 것이 없음)

정리

❗️PUT

역할

• 리소스를 대체
  • 리소스가 있으면 대체, 없으면 생성(덮어쓰기와 비슷)
• 클라이언트가 리소스를 식별
  • 클라이언트가 리소스 위치를 알고 URI를 지정
  • POST와의 차이점

리소스 처리 순서

• 리소스가 이미 있는 경우
  1. 리소스 전송
  2. 리소스 대체
     • 이 때 리소스를 완전히 대체함
     • 만약 {age: 50}으로 리소스를 대체하면 원래 리소스가 {name: "Junsesop", age: 27} 이었어도 name은 사라지고 age는 50으로 대체됨
  3. 응답 메시지 전송
• 리소스가 없는 경우
  1. 리소스 전송
  2. 신규 리소스 생성
  3. 응답 메시지 전송

❗️ PATCH

역할

• 리소스 부분 변경
• 리소스 변경 순서
  1. 부분 변경 요청 메시지 전송
  2. 리소스 부분 변경
     • PUT과 달리 name은 사라지지 않고 age만 50으로 변경
  3. 응답 메시지 전송

❗️ DELETE

역할

• 리소스 제거

리소스 제거 순서
1. 제거 요청 메시지 전송
2. 리소스 제거
3. 응답 메시지 전송

❗️ HTTP 메서드 정리

HTTP 메서드의 속성

• 안전(Safe Methods)
  • 호출해도 리소스를 변경하지 않음
• 멱등(Idempotent Methods)
  • f(f(x)) = f(x)
  • 한 번 호출하든 두 번 호출하든 결과가 똑같음
  • GET, PUT, DELETE는 같은 요청을 여러번 해도 결과는 똑같음
  • POST: 멱등이 아니다. 결제 시스템의 경우 두 번 호출하면 같은 결제가 중복해서 발생할 수 있음
  • 활용
    • 자동 복구 메커니즘
    • 서버가 정상 응답을 주지 못했을 때, 클라이언트가 같은 요청을 다시 해도 되는가에 대한 판단 근거
• 캐시가능(Cacheable Methods)
  • 응답 결과 리소스를 캐시해서 사용해도 되는가?
  • GET, HEAD, POST, PATCH는 캐시 가능
  • 실제로는 GET, HEAD 정도만 캐시로 사용(POST, PATCH는 구현이 쉽지 않음)