✏️ Achievement Goals
✅ 클라이언트-서버 콘셉트, 아키텍쳐를 이해할 수 있다.
✅ HTTP를 이용한 클라이언트-서버 통신을 이해할 수 있다.
✅ API의 개념을 이해할 수 있다.
✅ HTTP messages의 구조를 설명할 수 있다.
✅ HTTP의 동작 방식을 이해할 수 있다.
✅ HTTP requests와 responses를 구분할 수 있다.
✅ HTTP의 응답 메시지를 찾아볼 수 있다.
📝summary
1. 클라이언트-서버 아키텍쳐
리소스를 사용하는 앱(클라이언트)과 리소스가 존재하는 곳(서버)를 분리 시키는 것을 클라이언트 - 서버 아키텍쳐(2티어 아키텍쳐)라고 한다
앱을 사용했을때 인터넷 연결이 없으면 어플이 제대로 작동하지 않는다
그 이유는 앱의 정보를 인터넷에 존재하는 서버로부터 받아오기 때문이다
만약 쇼핑몰 앱이라고 가정했을때
판매하는 상품 정보 모두가 앱 안에 담겨있는 경우
앱과 연결된 서버가 존재하지 않는경우가 있다면 새로운 상품 목록을 받기 위해서 앱 자체를 계속해서 업데이트 해줘야 한다
그리고 서버가 없다면 결제를 할 수 없다
이처럼 클라이언트와 서버는 요청과 응답을 주고 받는 관계이고
클라이언트-서버 아키텍처에서는 요청이 선행되고, 그 후에 응답이 온다
1) 3-Tier 아키텍쳐
서버는 리소스를 전달 해줄 뿐이고 리소스는 데이터 베이스라는 창고에 저장해 둔다
클라이언트-서버 아키텍쳐에 데이터베이스가 추가된 형태를 3티어 아키텍쳐라고 한다
2) 프론트와 백엔드
웹 개발자 직군에 대해서 찾아보게되면 처음으로 듣게 되는 용어가 프론트엔드와 백엔드 개발자 인데
프론트와 백엔드는 아키텍쳐에서 어떤 분야를 다루느냐에 따라 나뉜다
클라이언트처럼 사용자가 눈으로 보고 UI클릭, 터치 하는 것 과 같은 상호작용을 할 수 있는 앱을 주로 개발하면 프론트엔드 개발자
사용자 눈에 보이지는 않지만 상품정보를 API로 노출, 로그인/로그아웃, 권한같은 사용자 인증을 다루는 개발자는 백엔드 개발자라고 한다
3) 클라이언트와 서버 종류
클라이언트는 플랫폼에 따라 구분되고
웹사이트, 스마트폰/태블릿용 앱, 데스크탑앱이 있다
서버는 어떤 것을 하냐에 따라 종류가 달라지는데
파일 서버 - 파일을 제공하는 앱
웹 서버 - 웹사이트에서 필요로 하는 정보들을 제공하는 앱(주로 만들게 될 서버)
메일 서버 - 메일을 주고 받을 수 있도록 도와주는 앱
데이터 베이스 - 데이터 제공자로서 일하기 때문에 서버라고 볼 수 있다
2. HTTP를 이용한 클라이언트-서버 통신
클라이언트와 서버가 데이터를 주고 받으려면 어떻게 주고 받을 것인지 약속을 해야한다 그 약속을 프로토콜 이라고 한다
1) 프로토콜이란?
프로토콜은 데이터 송수신에 필요한 통신 규약, 즉 약속이다
손님이 주문을 받는 사람에게 대뜸 찾아가, 외계어로 주문을 할 수 없듯, 주문을 하기 위해서는 꼭 지켜야 하는 약속이 몇가지 존재한다
웹 애플리케이션 아키텍처에서는 클라이언트와 서버가 서로 HTTP라는 프로토콜을 이용해서 서로 대화를 나누고
HTTP를 이용해 주고받는 메시지는 "HTTP 메시지"라고 부른다
이때 HTTP만의 규칙이 있다
2) HTTP 특징 : Stateless(무상태성)
Stateless는 말 그대로 상태를 가지지 않는다는 뜻이다
HTTP로 클라이언트와 서버가 통신을 주고 받는 과정에서, HTTP가 클라이언트나 서버의 상태를 확인하지 않는다
사용자는 쇼핑몰에 로그인하거나 상품을 클릭해서 상세 화면으로 이동하고, 상품을 카트에 담거나 로그아웃을 할 수도 있는데
클라이언트에서 발생한 이런 모든 상태를 HTTP 통신이 추적하지 않는다
만약 쇼핑몰에서 카트에 담기 버튼을 눌렀을 때, 카트에 담긴 상품 정보(상태)를 저장해둬야 한다
그러나 HTTP는 통신 규약일 뿐이므로, 상태를 저장하지 않는다
다른 방법(쿠키-세션, API 등)을 통해 상태를 확인할 수 있다
이 방법은 섹션 3에서 배운다!
3) HTTP 메세지
HTTP messages 는 클라이언트와 서버 사이에서 데이터가 교환되는 방식이고 HTTP messages에는 요청(Requests)과 응답(Responses)이 존재한다
start line : start line에는 요청이나 응답의 상태를 나타냅니다. 항상 첫 번째 줄에 위치합니다. 응답에서는 status line이라고 부릅니다.
HTTP headers : 요청을 지정하거나, 메시지에 포함된 본문을 설명하는 헤더의 집합입니다.
empty line : 헤더와 본문을 구분하는 빈 줄이 있습니다.
body : 요청과 관련된 데이터나 응답과 관련된 데이터 또는 문서를 포함합니다. 요청과 응답의 유형에 따라 선택적으로 사용합니다.
이 중 start line과 HTTP headers를 묶어 요청이나 응답의 헤드(head)라고 하고, payload는 body라고 이야기합니다.
4) HTTP 상태코드
1xx(정보) : 요청을 받았으며 프로세스를 계속 진행
2xx(성공) : 요청을 성공적으로 받았으며 인식했고 받아들임
3xx(리다이렉션) : 요청 완료를 위해 클라이언트의 추가 작업 조치가 필요
4xx(클라이언트 오류) : 요청의 문법이 잘못되었거나 요청을 처리할 수 없음
5xx(서버 오류) : 서버가 명백히 유효한 요청에 대한 충족을 실패
5) HTTP 요청 메서드
GET : 서버 자원을 가져오려 할 때 사용
POST : 서버에 자원을 새로 등록하려 할 때 사용(또는 어떤 메소드를 사용해야할 지 애매할때)
PUT(전체수정) : 서버의 자원을 요청에 들어있는 자원으로 바꿀때 사용
PATCH(부분수정) : 서버 자원의 일부만 수정할때 사용
DELETE : 서버 자원을 삭제할때 사용
3. API
API 는 쉽게 메뉴판으로 생각하면 된다
클라이언트가 서버에 요청할 때는 정확한 주문 방법에 따라 요청해야한다
손님이 커피를 주문 할때 “알아서 맛있게 타와”라는 요청은 허용되지 않고 컴퓨터는 0과 1로 변환될 수 있는 요청만 받는다
그렇다면 손님(클라이언트)은 어떻게 주문하는지 메뉴얼이 담긴
메뉴판을 달라고 요청 할 수 있다
서버는 클라이언트에게 리소스를 잘 활용할 수 있도록 인터페이스(interface)를 제공해줘야 한다.
클라이언트는 서버가 어떻게 구성되어 있는지 알 방법이 없기 때문에 서버가 인터페이스를 제공해야 하는데
이것을 API(Application Programming Interface)라고 한다
Interface의 사전적 의미는 “의사소통이 가능”하도록 만들어진 “접점”을 의미하기 때문에 메뉴판도 인터페이스라고 볼 수 있다
하지만 API는, 앱이 요청할 수 있고 프로그래밍 가능한 인터페이스라는 점이 다르다
서버가 리소스 전달을 위한 메뉴판, API를 만들어 놓아야 클라이언트가 이를 활용할 수 있다
인터넷에 있는 데이터를 요청할 때에는 HTTP라는 프로토콜을 사용하며, 주소(URL, URI)를 통해 API에 접근할 수 있다
이러한 API URL을 적절하게 디자인 해야한다.
