HTTP/네트워크 기초 Ch 1. 웹 애플리케이션 아키텍처
현재 코드스테이츠 강의를 통해 프론트엔드를 학습하고 있습니다.
본 포스트는 해당 강의에 대한 내용 정리를 목적으로 합니다.
학습목표
- 클라이언트-서버 아키텍처를 이해할 수 있다.
- HTTP를 이용한 클라이언트-서버 통신을 이해할 수 있다.
- API의 개념을 이해할 수 있다.
1. 클라이언트-서버 아키텍처
상품 정보 같은 리소스가 존재하는 곳과 리소스를 사용하는 앱을 분리시킨 것을 Client Server Architecture 혹은 2 Tier Architecture 라고 합니다. 리소스를 사용하는 앱이 바로 '클라이언트(client)', 리소스를 제공하는 곳은 '서버(server)'라고 부릅니다.
리소스에 접근하려는 앱은 마치 손님(Client)과 같아서, 리소스를 가지고 있는 점원(Server)에게 물품을 요청해야 합니다. 요청에 따라, 점원(Server)는 리소스를 담아 응답합니다.
클라이언트와 서버는 요청과 응답을 주고받는 관계입니다. 클라이언트-서버 아키텍처에서는 요청이 선행되고 그 후에 응답이 옵니다.
하지만 일반적으로 서버는 리소스를 전달해주는 역할만 담당합니다. 리소스를 저장하는 공간은 데이터베이스라는 곳입니다. 이처럼 클라이언트-서버 아키텍처에 데이터베이스가 추가된 형태를 3-Tier 아키텍처라고 합니다.
위 이미지처럼 프론트엔드 혹은 백엔드는 아키텍처에서 어떤 분야를 다루는지에 따라 구분됩니다.
클라이언트처럼 사용자가 직접 눈으로 보고, UI를 클릭 또는 터치하는 등의 상호작용을 할 수 있는 앱을 주로 개발하면 프론트엔드 개발자라고 합니다.
반면 사용자 눈에 보이지 않지만, 상품 정보를 API로 노출한다든지, 로그인/로그아웃, 권한 관리 등의 사용자 인증을 다루는 개발자는 백엔드 개발자라고 부릅니다.
백엔드 개발자는 데이터베이스 등의 시스템 설계까지 맡아서 하는 경우가 많습니다.
클라이언트와 서버의 종류
클라이언트는 보통 플랫폼에 따라 구분됩니다. 브라우저와 같은 웹(Web)플랫폼에서의 클라이언트는 웹 앱 , iOS나 안드로이드 같은 스마트폰/태블릿 플랫폼에서의 클라이언트는 스마트폰/태블릿용 앱, 윈도우와 같은 데스크탑 플랫폼에서 이용하는 데스크탑 앱 역시 클라이언트가 될 수 있습니다.
서버는 무엇을 하느냐에 따라 종류가 달라집니다.
파일 서버는 파일을 제공하는 앱, 웹 서버는 웹사이트에서 필요한 정보들을 제공하는 앱, 메일 서버는 메일을 주고받을 수 있도록 도와주는 앱입니다.
데이터베이스도 데이터 제공자로서 일하므로 일종의 서버라고 볼 수 있습니다.
2. 클라이언트 - 서버 통신과 API
클라이언트와 서버 간의 통신을 알아보기 위해 프로토콜의 개념을 이해하려 합니다.
프로토콜(Protocol) 은 통신 규약 즉 약속입니다.
웹 애플리케이션(웹 앱) 아키택처에서는 클라이언트와 서버가 서로 HTTP프로토콜을 이용해서 응답과 요청을 합니다.
HTTP를 이용해 주고받는 메시지는 "HTTP 메시지"라고 부릅니다.
또한 서버와 통신할 수 있는 다양한 방법(프로토콜)이 존재합니다.
위 OSI 7 계층은 네트워크에서 통신이 일어나는 과정을 7단계로 나눈 것을 말하며, 국제표준화기구(ISO)에서 네크워크 간의 호환을 위해 OSI 7계층이라는 표준 네트워크 모델을 만들었습니다.
OSI 7단계로 정의한 이유는 통신이 일어나는 과정을 단계별로 파악하기 위함과 통신 과정 중에 특정한 곳에 이상이 생길 경우에 다른 단계의 장비 및 소프트웨어 등을 건드리지 않고 통신 장애를 일으킨 단계에서 해결할 수 있기 때문입니다.
API(Application Programming Interface)
서버는 클라이언트에게 리소스를 잘 활용할 수 있도록 인터페이스(interface)를 제공해줘야 합니다 이것을 API(Application Programming Interface) 라고 합니다.
Interface의 사전적 의미는 "의사소통이 가능"하도록 만들어진 "접점"을 의미합니다.
API는 카페의 메뉴판과도 같습니다. 즉, 서버는 리소스 전달을 위한 메뉴판인 API 문서를 작성해야 클라이언트가 이를 잘 활용할 수 있습니다.
보통 인터넷에 있는 데이터를 요청할 때에는 HTTP라는 프로토콜을 사용하며, 주소(URL, URI)를 통해 접근할 수 있습니다.
HTTP API 디자인에는 Best Practice가 존재합니다.
HTTP 요청시 메소드를 지정하여 리소스와 관련된 행동(CRUD; create/read/update/delete)을 지정할 수 있습니다. 아래 표는 사용자 관리 API 예시입니다.
| 요청 | URL 디자인 | 사용하는 메서드 |
|---|---|---|
| 모든 사용자 조회(Read) | /users | GET |
| 새 사용자 추가(Create) | /users | POST |
| 1번 사용자 정보 갱신(Update) | /users/1 | PUT 또는 PATCH |
| 1번 사용자 정보 삭제(Delete) | /users/1 | DELETE |
| 1번 사용자 정보 조회 | /users/1 | GET |
