클라이언트-서버 아키텍처
2티어 아키텍처
리소스가 존재하는 곳과 리소스를 사용하는 앱을 분리시킨 것을 2티어 아키텍처, 또는 클라이언트-서버 아키텍처라고 부름
클라이언트와 서버는 요청과 응답을 주고받는 관계
요청이 선행되고 그 후에 응답이 옴
3티어 아키텍처
서버는 리소스를 전달해주는 역할을 담당하고 리소스를 저장하는 데이터베이스라는 별도의 공간을 따로 마련해둠
2티어 아키텍처 + 데이터베이스
클라이언트 앱이 프론트엔드, 서버 앱과 데이터베이스가 백엔드
API
프로토콜
통신 규약, 요청을 할 때 반드시 지켜야하는 양식
위의 7가지를 OSI 7Layers라고 통칭 (응용 계층)
Application Programming Interface
클라이언트가 리소스를 잘 활용할 수 있도록 서버가 인터페이스를 제공해주는 것
'의사소통이 가능하도록 만들어진 접점'
CRUD
브라우저의 작동 원리
URL과 URI
IP와 포트
IP(Internet Protocol address) : 네트워크에 연결된 특정 PC의 주소를 나타내는 체계
PORT : IP주소 뒤에 붙은 :3000 같은 숫자, IP 주소가 가리키는 PC에 접속할 수 있는 통로
AJAX
Asynchronous JavaScript And XMLHttpRequest의 약자로 웹 페이지의 필요한 부분에 필요한 데이터만 비동기적으로 받아와 화면에 그릴 수 있음
AJAX를 구성하는 핵심기술은 JavaScript와 DOM, Fetch
AJAX의 장점
서버에서 HTML을 완성해서 보내주지 않아도 웹 페이지를 만들 수 있음
이전에는 브라우저마다 다른 방식으로 AJAX를 사용했으나 XHR이 표준화되면서 브라우저에 상관없이 AJAX를 사용할 수 있게 되었음
AJAX를 사용하면 필요한 부분만 렌더링 하므로 빠르고 더 많은 상호작용이 가능한 어플리케이션을 만들 수 있음
필요한 데이터를 텍스트 형태(JSON 등)로 보내므로 보내는 데이터의 크기가 작음
(더 작은 대역폭)
AJAX의 단점
Search Engine Optimization(SEO)에 불리
AJAX 방식은 한번 받은 HTML을 렌더링 한 후 서버에서 비동기적으로 필요한 데이터를 가져와서 그려내므로 처음 받는 HTML파일에는 데이터를 채우기 위한 틀만 작성되어 있는 경우가 많음 즉 긁어갈 데이터가 없음
뒤로가기 버튼 문제
AJAX에서는 이전 상태를 기억하지 않으므로 뒤로가기가 동작하지 않음. 별도로 History API를 사용해야 함
SSR vs CSR
SSR
Server Side Rendering
웹 페이지를 브라우저에서 렌더링하는 대신 서버에서 렌더링
브라우저가 서버로 GET 요청을 보내면 서버가 웹 페이지 파일을 브라우저로 전송, 브라우저에 도착하면 완전히 렌더링됨
브라우저가 다른 경로로 이동할 때마다 서버가 작업을 수행
CSR
Client Side Rendering
웹 페이지를 클라이언트에서 렌더링
대표적인 예시가 웹 브라우저
브라우저의 요청을 서버로 보내면 서버는 렌더링하는 대신 웹 페이지의 골격이 될 단일 페이지를 JavaScript 파일과 함께 클라이언트로 보내고 브라우저에서 받아서 렌더링
필요한 파일이 데이터베이스에 있을 경우 API 요청을 통해 해소
HTTP
Hyper Text Transfer Protocol
HTML과 같은 문서를 전송하기 위한 Application Layer 프로토콜
HTTP messages
클라이언트와 서버 사이에서 데이터가 교환되는 방식
요청(Request)과 응답(Response)이 있음
start line : 요청이나 응답의 상태, 항상 첫번째 줄에 위치함 (응답에서는 status line)
HTTP headers : 요청을 지정하거나 메세지에 포함된 본문을 설명하는 헤더의 집합
empty line : 헤더와 본문을 구분하는 빈 줄
body : 요청과 관련된 데이터나 응답과 관련된 데이터 또는 문서를 포함, 요청과 응답의 유형에 따라 선택적으로 사용
요청 (Request)
Headers
헤더 이름, 콜론, 값의 구조
General headers : 메세지 전체에 적용되는 헤더로 body를 통해 전송되는 데이터와는 관련 X
Request headers : fetch를 통해 가져올 리소스나 클라이언트 자체에 대한 자세한 정보를 포함
Representation headers : body에 담긴 리소스 정보를 포함하는 헤더
Body
요청의 본문은 HTTP messages 마지막에 위치, 모든 요청에 필요한 건 아님
GET, DELETE 처럼 서버에 리소스를 요청하는 경우에는 본문이 필요하지 않음
POST나 PUT같은 일부 요청은 데이터를 업데이트하기 위해 사용
Single-resource bodies(단일 리소스 본문) : 헤더 두개가 정의된 단일 파일
Multiple-resource bodies(다중 리소스 본문) : 여러 파트로 구성, 각 파트마다 다른 정보
응답 (Response)
Status line
현재 프로토콜의 버전
상태 코드 : 요청의 결과(404, 200 등)
상태 텍스트 : 상태 코드에 대한 설명
Headers
요청 헤더와 동일한 구조를 가지고 있음
Body
요청 body와 같이 모든 응답에 필요하지 않음, 201, 404 같은 상태 코드를 가지는 응답에는 본문이 필요하지 않음
Stateless
HTTP의 특징으로 '무상태성'을 의미
HTTP로 클라이언트와 서버가 통신을 주고받을 때 클라이언트나 서버의 상태를 확인하지 않음
