HTTP에 대하여

Spring Boot에 대해 배우기 이전에,
간단하게 HTTP에 대하여 짚고 넘어가보자!

*HyperText Transfer Protocol

아래와 같은 형태의 Data들을 HTTP 규약에 따라 전송이 가능하다.

현재 HTTP/1.1 Version을 가장 많이 사용하고, 우리에게 중요하다.

Stateful : Server가 Clinet의 상태를 보존한다.
- Client의 상태를 보존하기 때문에, Client는 요청을 끊어서 할 수 있다.
- 하지만 Server는, 중간에 마음대로 바뀔 수 없다.
- Server가 바뀔 때엔 상태를 모두 넘겨주고 바뀌어야 한다!
Stateless : Server는 Client의 상태를 보존하지 않는다.
- Server가 바뀌는 경우엔?
- 어차피 Client가 필요 정보를 모두 담아서 보내기 때문에, 상관이 없다.
- 갑자기 Client가 증가해도 Server를 대거 투입할 수 있다!
Stateless의 실무 한계
- 모든 것을 무상태로 설계할 수 없는 경우도 있다.
  - ex) 로그인, 상태 유지가 필요하다.
  - 일반적으로 쿠키, 세션 등을 생성해서 상태를 유지한다.
- 하지만 최대한 무상태로 설계를 하도록 노력한다.

여러 Client들에 동시에 응답하는 경우엔 서버는 어떨까?
- 동시에 여러 연결을 유지를 하고 있다면, 자원이 낭비될 것이다.
요청을 주고 받을 때만 연결을 유지하고, 다른 땐 끊어버린다면?
- 서버는 최소한의 자원만을 사용할 수 있다.
HTTP는 기본적으로 연결을 유지하지 않는 모델이다.
- 일반적으로 초 단위의 빠른 속도로 응답을 하기 때문이다.
- 1시간 동안 수천명이 서비스를 사용해도, 동시 처리되는 요청은 매우 적다.
한계점
- 매번 TCP/IP 연결을 새로 맺어야 한다.
  - 3 Way Handshake Overhead (Client 입장에서 단점)
- Web browser로 요청을 넣으면, HTML뿐만 아니라 CSS, 추가 이미지 등 수많은 자원이 동시에 다운로드 된다.
현재는 Persistent Connection으로 문제를 해결했다.

화면 캡처 2022-06-30 203900

위 설계 방식은 과연 좋은 설계인가? 그렇지 않다!

Resource의 의미는 무엇일까?
- 회원에 대한 동작이 Resource가 아니다.
- 회원 그 자체가 Resource가 된다.
- 그에 맞춰서 Resource 중저 URI를 설계 해보자.
Resource 중점의 URI 설계
- 회원 목록 조회 /members
- 회원 조회 /members/{id}
- 회원 등록 /members/{id}
- 회원 수정 /members/{id}
- 회원 삭제 /members/{id}

이렇게 설계를 하면 조회, 등록, 수정, 삭제를 어떻게 구분할 것인가? 그럼 Resource(명사)와 행위(동사)를 분리하자!

GET : Resource 조회
- 전달하고자 하는 Data를 Query Parameter(String)으로 전달.
- Body로도 전달 가능하지만, 지원하는 곳이 많이 없다.
POST : 요청 Data 처리. 주로 등록하는 데에 사용.
- Body를 통해서 요청 Data를 전달한다.
- 주로 신규 Resource 등록, Process 처리에 사용한다.
- POST 요청이 오면, 어떻게 처리할지 Resource 마다 정해주어야 한다.
- 어떤 Method로 처리하기 애매한 경우에, 그냥 POST를 쓰기도 한다.
PUT : Resourec를 대체, 없으면 새로 생성
- 기존 Resource를 덮어쓰기(완전 대체) 한다.
  - ex) name과 age가 이미 있을 때, age만 보내면 name은 없어진다.
- POST와의 차이는, Client가 리소스 URI를 지정한다는 것!
PATCH : Resource 수정
- Patch는 Put과 다르게 Resource 중 일부만 보내도 수정이 된다.
- 만약 Patch가 지원이 안되는 서버라면 Post를 쓰자!
DELETE : Resource 삭제
HEAD : GET과 유사하지만, Header와 Status Line만 반환.
OPTIONS : 통신 가능한 Method 목록을 반환

Safe
- 호출해도 Resource를 변경하지 않는다.
- GET이 안전한 Method 중 하나이다.
Idempotent
- 몇 번을 호출해도 결과가 바뀌지 않는다.
- GET, PUT, DELETE 가 멱등 Method이다.
- POST는 멱등성이 없다!
  - 중복 호출 시, 같은 결제가 중복해서 발생할 수가 있다!
- 자동 복구 메커니즘에 활용되는 성질이다.
  - 서버가 정상 작동을 하지 않을 때, 같은 요청을 받아도 되는가?
Cacheable
- 응답 결과 Resource를 Cache해서 사용해도 되는가?
- GET, HEAD, POST, PATCH는 Cache 가능.
  - 하지만 실제로는 GET, HEAD 정도만 사용한다.
  - POST와 PATCH는 본문 내용까지 고려를 해야해서 구현이 어렵다.

정적 Data 조회
- GET Method와, URI 경로만 지정해서 요청을 한다.
- 단순히 조회 결과만 응답에 보낸다.
- Query Parameter 없이 조회 가능!
동적 Data 조회
- 이 경우에는 Query Parameter이 필요하다.
  - Query Parameter을 이용하는 GET Method를 이용한다.
- URI에 Query Parameter을 포함시켜서 요청을 보낸다.
- 주로 검색이나 게시판 목록, 정렬 필터(검색어)에 쓰인다.
HTML Form Data 전송
- 우리는 HTML의 Form 태그를 Data를 전송받을 때 주로 사용한다.
- POST Method를 통해서 Data와 함께 요청을 전송한다.
- Form의 내용을 Message body를 통해서 전송 (Key = Value 형식)
- application/x-www-form-urlencoded에 의해 Url이 Encoding 처리.
- HTML Form은 GET 전송도 가능하다.
  - 하지만 Resource 변경이 일어나는 경우는 POST를 써야한다!
HTML API Data 전송
- application/json을 Content-Type으로 POST Method를 사용한다.
- JSON 형태로 Data를 Body에 넣어서 전송한다.
- 어떤 상황에서 주로 사용하나요?
  - Server와 Server 간에 통신할 때
  - App Client를 대상으로 통신할 때
  - Web Client를 대상으로 Javascript를 이용할 때 사용.

사진 및 자료 출처 : [김영한의 HTTP 웹 기본 지식]https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC/dashboard)