(SEB_FE) Section2 Unit2 네트워크 복습

🍎클라이언트와 서버는 어떻게 통신할까?

클라이언트와 서버 간의 통신은 요청과 응답으로 구성된다.
즉, 클라이언트로부터의 요청이 있어야, 서버에서는 응답을 보낼 수 있다.

클라이언트와 서버가 대화를 할 때는, 커피를 주문하는 사람이 외계어로 주문할 수 없듯이, 지켜야하는 규칙이 몇 가지 존재한다.
그 규칙이 바로, 통신 규약 "프로토콜"

웹 애플리케이션 아키텍처에서는 클라이언트와 서버가 서로 HTTP(HyperText Transfer Protocol)라는 프로토콜을 이용해서 서로 대화를 나눈다. 이때 HTTP를 이용해서 주고받는 메시지가 바로 "HTTP 메시지"이다.

커피를 주문하는 방법은, 카운터로 찾아가거나, 앱을 이용하거나, 키오스크를 이용하는 등, 다양하게 존재한다. 이런 방법 하나하나가 전부 프로토콜이다.
즉, 같은 일을 하기 위해 "다양한 방법"이 존재할 수 있는 것!

기억하자. 프로토콜은 "여러 개"가 존재한다.
그리고 그 각각의 프로토콜마다 지켜야 하는 규약이 존재한다.

🍒OSI 7 Layers

프로토콜이 여러 개라고 했는데, 어떤 게 있을까?

• 프로토콜은 총 7계층으로 나눌 수 있다.
  중요한 건 4. 전송 계층(TCP, UDP)과 7. 응용 계층(여기에 HTTP가 있다)

🍒API (Application Programming Interface)

클라이언트는 어떻게 리소스를 서버에게 요청할까?
답은, "API를 이용해서" 이다.

그렇다면 API는 뭘까?

서버는 클라이언트에게 리소스를 잘 활용할 수 있도록 제공하는 인터페이스로, 가게의 메뉴판과도 같다. 즉, 리소스 전달을 위한 메뉴판!

보통 인터넷에 있는 데이터를 요청할 때에는 HTTP라는 프로토콜을 사용하며, 주소(URL, URI)를 통해 접근할 수 있다. (HTTP API)
➡ 이게 뭔 소리인지 이제 다시 한번 알아보자.

🍎URL과 URI

• URL은 Uniform Resource Locator의 줄임말로, 네트워크 상에서 웹 페이지, 이미지, 동영상 등의 파일이 위치한 정보

• URI는 Uniform Resource Identifier의 줄임말로, 일반적으로 URL의 기본 요소인 scheme, hosts, url-path에 더해 query, fragment를 포함

  • scheme는 통신 프로토콜

  • hosts(IP Address)는 웹 페이지, 이미지, 동영상 등의 파일이 위치한 웹 서버, 도메인 또는 IP

  • url-path는 웹 서버의 루트 디렉토리로부터 웹 페이지, 이미지, 동영상 등의 파일이 위치까지의 경로

  • query는 웹 서버에 보내는 추가적인 질문

  • port는 IP 주소가 가리키는 PC에 접속할 수 있는 통로(채널)

  🔽http://www.google.com:80/search?q=JavaScript 라는 API로 살펴보자.🔽

  scheme는 http:// 부분 이며
  hosts는 www.google.com 부분이고
  (IP는 127.0.0.1로, 이 IP의 도메인 네임이 www.google.com 인 것임)
  port는 :80 이고 (참고로 80은 http의 포트)
  url-path는 /search 부분이며
  query는 q=JavaScript이다.

  이 메뉴(HTTP API)를 서버에 보낸다는 건 뭘 의미할까?

  http 통신 프로토콜로
  www.google.com 서버에
  :80 포트, 즉 :80이라는 길, 통로로 접속해서
  /search 경로를 지나
  q=JavaScript 질문에 해당하는 응답을 줘!
  (즉, google에 JavaScript를 검색했을 때 검색 결과를 달라는 말)

  그러면 클라이언트는 그 검색 결과를 보기 좋게 예쁘게 배치하면 된다.

🍎HTTP Requests

그럼 HTTP 메시지는 어떻게 보내는지 한번 알아보자.

HTTP Requests는 사등신이다!

글로 죽 나열되어 있어서 어디가 사등신인가 싶겠지만, 자세히 뜯어보면
startline, HTTP headers, empty line, body로 나눌 수 있다!

1. start line : start line에는 요청이나 응답의 상태를 나타냄. 항상 첫 번째 줄에 위치. 응답에서는 status line이라고 부른다.

2. HTTP headers : 요청을 지정하거나, 메시지에 포함된 본문을 설명하는 헤더의 집합.

3. empty line : 헤더와 본문을 구분하는 빈 줄.

4. body : 요청과 관련된 데이터나 응답과 관련된 데이터 또는 문서. 요청과 응답의 유형에 따라 선택적으로 사용. (필수 아님)

• GET, HEAD, DELETE, OPTIONS처럼 서버에 리소스를 요청하는 경우에는 본문이 필요하지 X
• 201, 204와 같은 상태 코드를 가지는 응답에는 body 필요 X

이 중 start line과 HTTP headers를 묶어 요청이나 응답의 헤드(head)라고 하고, payload는 body라고 한다.

🍒요청의 헤더

🍒응답의 헤더

HTTP로 클라이언트와 서버가 통신을 주고받는 과정에서, HTTP가 클라이언트나 서버의 상태를 확인하지 않는다.
이러한 Stateless(무상태성)가 HTTP의 큰 특징

🍎AJAX

• AJAX의 가장 큰 특징은, 웹 페이지에 필요한 부분에 필요한 데이터만 비동기적으로 받아와 화면에 그려낼 수 있다는 점.

• AJAX를 구성하는 핵심 기술은 JavaScript와 DOM, 그리고 Fetch(XHR의 단점을 보완한 새로운 Web API)

🍎REST API

웹에서 사용되는 모든 데이터나 자원(Resource)을 HTTP URI로 표현하고, HTTP 프로토콜을 통해 요청과 응답을 정의하는 방식

🍒 REST 성숙도 모델 - 0단계

HTTP 프로토콜을 사용하기

🍒 REST 성숙도 모델 - 1단계

개별 리소스(Resource)와의 통신을 준수하기

• 모든 자원은 개별 리소스에 맞는 엔드포인트(Endpoint)를 사용해야 하며
  요청하고 받는 자원에 대한 정보를 응답으로 전달해야 한다

  • ex) 엔드포인트란? -> /appointment, /search 등
  • 엔드포인트 작성 시에는 동사, HTTP 메서드, 혹은 어떤 행위에 대한 단어 사용은 지양하고, 리소스에 집중해 명사 형태의 단어로 작성하자

• 응답으로 리소스를 전달할 때에도 사용한 리소스에 대한 정보와 함께 리소스 사용에 대한 성공/실패 여부를 반환해야 한다.

🍒 REST 성숙도 모델 - 2단계

CRUD에 맞게 적절한 HTTP 메서드를 사용 하기

1. GET 메서드 같은 경우는 서버의 데이터를 변화시키지 않는 요청에 사용하자.

2. POST 메서드는 요청마다 새로운 리소스를 생성하고
   PUT 메서드는 요청마다 같은 리소스를 반환.
   PUT이나 GET처럼 매 요청마다 같은 리소스를 반환하는 특징을
   멱등(idempotent)하다 고 한다.
   ➡ 때문에 멱등성을 가지는 메서드 PUT과 그렇지 않은 메서드 POST는 구분하여 사용해야 한다.

3. PUT 메서드와 PATCH 메서드도 구분하여 사용하자. PUT은 교체, PATCH는 수정의 용도로 사용하도록!