오늘은 HTTP에서 사용하는 클라이언트 - 서버 아키텍처와 클라이언트와 서버가 통신하는 방법인 API 에 대해 정리해보겠다.
클라이언트-서버 아키텍처란 ?
리소스가 존재하는 곳과 리소스를 사용하는 앱을 분리시킨 것
리소스를 제공 : 서버
리소스를 사용 : 클라이언트
+ ) 클라이언트-서버 아키텍처를 2 티어 아키텍처라 하며 추가로 리소스를 저장하는 공간인 데이터베이스까지 추가 된 형태는 3티어 아키텍처라 한다.
따라서 현재 내가 꿈꾸는 프론트엔드 개발자는 클라이언트 영역에서 이루어지는 개발을 주로 한다. 사용자가 직접 눈으로 보고 터치하는 상호작용을 주로 개발하게 된다.
이렇듯 클라이언트와 서버 간 통신을 통해 리소스를 요청하고 응답받게 되는데 마음대로 원하는 방식대로 통신하는 것이 아닌 통신 규약인 프로토콜에 따라서 통신이 이루어진다. 즉 지켜야 할 약속이 몇가지 존재한다.
+) 프로토콜 == 약속
클라이언트와 서버 간의 통신 ?
HTTP 라는 프로토콜을 이용함
HTTP 프로토콜 : 인터넷에 있는 데이터를 요청할 때 사용 , 주소 (URL ,URI )를 통해 접근
HTTP 메세지 : HTTP를 이용해 주고 받는 메세지
ex) GET / americano HTTP/1.1
프로토콜 ? 약속 ? 정의만 봐서는 이해가 어렵다. 예시를 들자면 스타벅스에 가서 주문을 한다고 가정할 때 카운터에서 직원에게 직접 주문을 하거나 , 키오스크를 이용하거나 , 스타벅스 앱을 통해 주문을 할 수 있다. 이런 방법들이 모두 프로토콜이다. 왜 ? 주문을 하기 위한 하나의 약속이기 때문이다. 음료를 시키기 위해선 다양한 방법이 존재할 수는 있지만 약속은 지켜야한다. 스타벅스에 가서 대자로 눕는다고 커피가 나오진 않는다. 메뉴 이름을 말하고 결제를 함으로써 음료를 시킬 수 있듯 프로토콜 또한 반드시 지켜야 할 규약이 있다.
프로토콜의 종류
https://ko.wikipedia.org/wiki/%EC%9D%B8%ED%84%B0%EB%84%B7_%ED%94%84%EB%A1%9C%ED%86%A0%EC%BD%9C
그래서 프로토콜을 통해서 통신하는건 OK
클라이언트 입장에선 서버가 어떻게 구성되어 있는지 모르는데 리소스를 어떻게 확인하지 ?
-> API 를 이용
API 는 서버측에서 클라이언트에게 리소스를 잘 활용할 수 있도록 인터페이스를 제공한 것
다시한번 스타벅스로 예를 들자면 API 는 메뉴판 같은 것이다. 스타벅스에 처음 가는 사람이어도 메뉴판을 보고 주문을 할 수 있듯 API 를 통해 클라이언트는 올바른 리소스를 요청할 수 있어야 한다.
예를 들어 아메리카노 한잔 주세요 -> /coffee/americano 처럼 URL 디자인을 통해 클라이언트는 아메리카노를 주문할 수 있게 된다.
HTTP API 디자인 좋은 예시
+) 리소스와 관련된 행동 (CRUD : create/read/update/delete)
HTTP 요청 메세지
https://developer.mozilla.org/ko/docs/Web/HTTP/Methods
URL 란 ?
네트워크 상에서 웹 페이지, 이미지 ,동영상 등의 파일이 위치한 정보를 나타냄
scheme, hosts, url-path 로 구분할 수 있음
scheme : 프로토콜을 결정
ex ) file:// , http://
hosts : 웹 서버의 이름이나 도메인, IP를 사용하며 주소를 나타냄
ex ) 127.0.0.1 , www.google.com
url-path : 웹 서버에 지정한 루트 디렉토리부터 시작하여 웹 페이지, 이미지, 동영상 등이 위치한 경로와 파일명을 나타냄
ex) /search
URI 란?
URL의 기본요소에 더해 query, fragment 를 포함함
query : 웹 서버에 보내는 추가적인 질문
ex) http://www.google.com:80/search?q=JavaScript
-> 구글에서 JavaScript 를 검색한 결과
fragment : 북마크 기능 , URL에 특정 HTML 요소의 id 를 전달하면 해당 요소가 있는 곳으로 스크롤 이동
브라우저의 검색창을 클릭하면 나타나는 주소가 URI 이다.
URI는 URL 을 포함하는 상위 개념
IP와 Port ?
IP adress : 네트워크에 연결된 특정 PC 주소 ,네 덩이 숫자로 구분됨
ex) IPv4 : 168.126.63.1
각 덩이는 0~255까지 나타낼 수 있어 43억개의 주소를 표현할 수 있음
Port : IP 주소에 진입할 수 있는 정해진 통로
포트번호는 0~ 65535 까지 사용 가능
0~1024 번은 이미 정해진 포트 번호
ex)HTTP : 80 , React : 3000
Domain name?
ip 주소를 대신하여 사용하는 주소
ex) 네이버 : naver.com / 125.209.222.142
DNS ?
도메인 이름과 매칭된 IP주소를 관리하는 서버
HTTP는 HyperText Transfer Protocol의 줄임말로, HTML과 같은 문서를 전송하기 위한 프로토콜이다 . HTTP는 웹 브라우저와 웹 서버의 소통을 위해 디자인되었다. 전통적인 클라이언트-서버 모델에서 클라이언트가 HTTP Messages 양식에 맞춰 요청을 보내면, 서버도 HTTP Messages 양식에 맞춰 응답한다.
HTTP Message?
클라이언트와 서버 사이에 데이터가 교환되는 방식
요청(Request) / 응답(Response)
구조
start line : start line에는 요청이나 응답의 상태를 나타냅니다. 항상 첫 번째 줄에 위치합니다. 응답에서는 status line이라고 부릅니다.
HTTP headers : 요청을 지정하거나, 메시지에 포함된 본문을 설명하는 헤더의 집합입니다.
empty line : 헤더와 본문을 구분하는 빈 줄이 있습니다.
body : 요청과 관련된 데이터나 응답과 관련된 데이터 또는 문서를 포함합니다. 요청과 응답의 유형에 따라 선택적으로 사용합니다
이 중 start line과 HTTP headers를 묶어 요청이나 응답의 헤드(head)라고 하고, payload는 body라고 이야기합니다.
Stateless(무상태성)?
HTTP로 클라이언트와 서버가 통신을 주고받는 과정에서 HTTP가 클라이언트나 서버의 상태를 확인하지 않는 것 . HTTP는 통신 규약일 뿐 상태를 저장하지 않음 . 필요에 따라 쿠키, 세션 등을 통해 상태를 확인할 수 있음
'코드스테이츠44기 프론트엔드' 카테고리의 다른 글
Postman 사용하기 (0) | 2023.03.30 |
---|---|
REST API 완벽 이해하기 (0) | 2023.03.29 |
fetch API 실습 (0) | 2023.03.22 |
[코드스테이츠 44기 프론트엔드 블로깅] 프로토타입 체인에 대해 (0) | 2023.03.16 |
[코드스테이츠 44기 프론트엔드 블로깅] 프로토타입과 클래스에 대해 (1) | 2023.03.15 |