클라이언트 서버 아키텍처 ( 2티어 아키텍처)
인터넷 연결이 없다면 쇼핑몰 앱은 정상적으로 동작할 수 없다.
그 이유는 상품 정보를 인터넷 어딘가에 존재하는 서버로부터 받아오기 때문이다.
*서버(server)는 제공(serve)하는 주체이다.
ex) 만약에 앱과 연결된 서버가 없다면 ? - 끊임없이 앱을 업데이트 해야하며, 실시간으로 정보를 전달하기 어려움 (신상품, 상품 결제 등 )
상품 정보같은 리소스가 존재하는 곳과 리소스를 사용하는 앱을 분리시킨 것을 2티어 아키텍쳐 or 클라이언트- 서버 아키텍쳐라고 부름
리소스를 사용하는 앱을 "클라이언트" , 리소스를 제공(serve)하는 곳은 "서버"라고 부름
Ex) 클라이언트(client, 손님)와 서버(server, 서빙하는 사람)라는 단어의 어원을 떠올리면 보다 이해가 쉽다.
리소스에 접근하려는 앱은 카페로 치면 손님과 같습니다. 손님은 아메리카노를 획득하기 위해 리소스를 가지고 있는 점원에게 요청해야 합니다. 손님의 요청에 따라 점원은 리소스를 담아 응답합니다.
이처럼 클라이언트와 서버는 요청과 응답을 주고받는 관계입니다.
클라이언트-서버 아키텍처에서는 요청이 선행되고 그 후에 응답이 옵니다.
요청하지도 않았는데 응답이 오는 경우는 없습니다.
리소스를 저장하는 공간을 별도로 마련해 두는데 이 공간은 "데이터베이스"
일반적으로 서버는 리소스를 전달해주는 역할만 담당.
그리고 데이터 베이스는 리소스를 저장하는 는 창고와 같은 역할을 함
기존 2티어 아키텍처에 데이터베이스가 추가된 형태를 3티어 아키텍처라고 부름
클라이언트와 서버 종류
클라이언트
클라이언트는 보통 플랫폼에 따라 구분
브라우저를 통해 주로 이용하는 웹(Web) 플랫폼에서의 클라이언트는 웹사이트 또는 웹 앱이라고 부름
iOS나 안드로이드와 같은 스마트폰/태블릿 플랫폼, 그리고 윈도우와 같은 데스크탑 플랫폼에서 이용하는 앱 역시 클라이언트가 될 수 있음
서버
서버는 무엇을 하느냐에 따라 종류가 달라짐
파일 서버 - 파일을 제공하는 앱, 웹 서버는 웹사이트에 따라서 필요로 하는 정보들을 제공하는 앱
메일 서버 - 메일을 주고 받을 수 있도록 도와주는 앱
데이터베이스 서버 - 데이터 제공자로서 일하는 일종의 서버의 개념으로 볼 수 있음.
클라이언트 - 서버 통신과 API
클라이언트와 서버 간의 통신은 요청과 응답으로 구성, 그리고 요청이 있어야만 응답을 함.
-> 클라이언트 - 서버 아키텍처에서는 서버 마음대로 클라이언트에 리소스에 전달하지 않습니다.
프로토콜
프로토콜은 통신 규약, 즉 약속입니다.
웹 애플리케이션 아키텍처에서는 클라이언트와 서버가 서로 HTTP라는 프로토콜을 이용해서 서로 대화를 나눕니다.
HTTP를 이용해 주고받는 메시지는 "HTTP 메시지"라고 부릅니다.
ex) 같은 일을 하기위해 다양한 방법을 사용할 수 있음 스타벅스에서 커피를 주문하기위해 카운터로 찾아가거나, 앱을 이용하거나, 키오스크를 이용하는 여러가지 선택지가 있듯이.
규약이라는 측면에서의 프로토콜
프로토콜은 각자의 프로토콜마다 지켜야 하는 규약이 존재합니다.
프로토콜의 종류
응용 계층
HTTP - 웹에서 HTML, JSON 등의 정보를 주고받는 프로토콜
HTTPS - HTTP에서 보안이 강화된 프로토콜
FTP - 파일 전송 프로토 콜
SMTP - 메일을 전송하기 위한 프로토콜
SSH - CLI 환경의 원격 컴퓨터에 접속하기 위한 프로토콜
RDP - Windows 계열의 원격 컴퓨터에 접속하기 위한 프로토콜
WebSocket - 실시간 통신, Push등을 지원하는 프로토콜
전송 계층
TCP - HTTP, FTP 통신의 근간이 되는 인터넷 프로토콜
UDP - (양방향의 TCP와는 다르게) 단방향으로 작동하는 훨씬 더 단순하고 빠르지만, 신뢰성이 낮은 인터넷 프로토콜
HTTP를 이용한 클라이언트-서버 통신과 API
API
우리는 서버가 어떻게 구성되어 있는지 알 방법이 없고, 우리가 서버 코드를 직접 짠 사람도 아닌데, 사용 가능한 자원을 파악할 수도 없다.
이에 대한 정답이 바로 API!
서버는 클라이언트에게 리소스를 잘 활용할 수 있도록 인터페이스(interface)를 제공해 줘야 한다.
API는 Application Programming Interface의 약자, Interface의 사전적 의미는 "의사소통이 가능"하도록 만들어진 "접점"을 의미합니다.
이 의미에 따르면, 메뉴판도 인터페이스라고 볼 수 있음.
다만 API는 앱이 요청할 수 있고 프로그래밍 가능한 인터페이스라는 점이 다름
서버가 리소스 전달을 위한 메뉴판, 즉 API를 구축해놓아야 클라이언트가 이를 활용할 수 있음.
보통 인터넷에 있는 데이터를 요청할 때에는 HTTP라는 프로토콜을 사용하며, 주소(URL, URI)를 통해 접근할 수 있게 됩니다.
HTTP API 디자인에는 Best Practice가 존재.
실제로 쓰일법한 API를 소개하자면 사용자 관리 API.
URL 디자인은 비교적 단순하나 "메소드"라는 개념이 등장.
HTTP 요청에는 메소드라는 것이 존재합니다.
사용자 관리 API에서는 사용자를 추가해 달라고(CREATE) 요청하거나, 지워달라고(DELETE) 요청할 수도 있음 마치 CRUD 행동과 비슷
CRUD 각각의 행동과 일치하는 HTTP 메소드의 종류가 존재합니다.
CRUD
대부분의 컴퓨터 소프트웨어가 가지는 기본적인 데이터 처리 기능인 Create(생성), Read(읽기), Update(갱신), Delete(삭제)를 묶어서 일컫는 말
댓글