클라이언트
서버 아키텍처
서버(server)는 영어 단어 그대로 제공(serve)하는 주체다.
정보 같은 리소스가 존재하는 곳과 리소스를 사용하는 앱을 분리시킨 것을 2티어 아키텍처, 또는 클라이언트-서버 아키텍처라고 부른다.
리소스를 사용하는 앱이 바로 "클라이언트", 리소스를 제공(serve)하는 곳은 "서버"라고 부른다.
클라이언트(client, 손님)와 서버(server, 서빙하는 사람)라는 단어의 어원을 떠올리면 보다 이해가 쉽다.
리소스에 접근하려는 앱은 카페로 치면 손님과 같다. 손님은 아메리카노를 마시기 위해 리소스를 가지고 있는 점원에게 요청해야 한다. 손님의 요청에 따라 점원은 리소스를 담아 응답한다.
이처럼 클라이언트와 서버는 요청과 응답을 주고받는 관계다. 클라이언트-서버 아키텍처에서는 요청이 선행되고 그 후에 응답이 온다.
일반적으로 서버는 리소스를 전달해 주는 역할만 담당한다. 리소스를 저장하는 공간을 별도로 마련해 두는데 이 공간을 "데이터베이스"라고 부른다.
이처럼 기존 2티어 아키텍처에 데이터베이스가 추가된 형태를 3티어 아키텍처라고 부른다.
서버 통신과 API
다시 한번 상점의 상품 제공자와 손님의 관점으로 돌아가 보자. 적절한 예를 들기 위해 커피 전문점을 예로 들어보자.
클라이언트와 서버 간의 통신은 요청과 응답으로 구성된다. 요청이 있어야만 응답이 온다.
주문하지 않은 커피가 갑자기 나올 수도 있겠지만, 보통은 손님으로부터 주문이 들어가야 커피가 나온다.
클라이언트-서버 아키텍처에서는 서버 마음대로 클라이언트에 리소스를 전달하지 않는다.클라이언트와 서버 간의 통신은 요청과 응답으로 구성된다.
클라이언트와 서버 간의 통신을 알아보려면, 먼저 프로토콜이라는 개념을 이해해야 한다.
프로토콜은 통신 규약, 즉 약속이다. 손님이 주문을 받는 사람에게 대뜸 찾아가 외계어로 주문을 할 수 없듯, 주문을 하기 위해서는 꼭 지켜야 하는 약속이 몇 가지 존재한다.
웹 애플리케이션 아키텍처에서는 클라이언트와 서버가 서로 HTTP라는 프로토콜을 이용해서 서로 대화를 나눈다. HTTP를 이용해 주고받는 메시지는 "HTTP 메시지"라고 부른다.
- 주요 프로토콜
우리는 서버가 어떻게 구성되어 있는지 알 방법이 없다. 우리가 서버 코드를 직접 짠 사람도 아닌데, 어떻게 사용 가능한 자원을 파악할 수 있을까?
이에 대한 정답이 바로 API(Application Programming Interface)다. 서버는 클라이언트에게 리소스를 잘 활용할 수 있도록 인터페이스(interface)를 제공해 줘야 한다. 이것을 API라고 한다.
API는 Application Programming Interface의 약자이며, Interface의 사전적 의미는 "의사소통이 가능"하도록 만들어진 "접점"을 의미한다.
쉽게 스타벅스를 예를 들어 생각해 보면, 메뉴판과 같은 역할을 한다고 볼 수 있다.
클라이언트가 스타벅스가 제공하는 자원의 종류(아메리카노, 콜드브루, 프라푸치노 등)를 모른다고 가정할 경우, 엉뚱한 메뉴(예를 들어 설렁탕)를 시키지 않도록 도와주어야 한다.
스타벅스가 "고객님은 콜드브루, 아메리카노와 같은 메뉴를 주문할 수 있습니다" 라고 메뉴판을 만들어 놓았기 때문에, 우리는 이에 맞게 적절한 요청("아메리카노 주세요!")을 할 수가 있는 것이다.
마찬가지로 서버가 리소스 전달을 위한 메뉴판, 즉 API를 구축해놓아야 클라이언트가 이를 활용할 수 있다.
보통 인터넷에 있는 데이터를 요청할 때에는 HTTP라는 프로토콜을 사용하며, 주소(URL, URI)를 통해 접근할 수 있게 된다.
위의 예제는 스타벅스 API 서버가 제공하는 적절한 URL 디자인이다. 파라미터를 사용하기 위해 물음표(?)와 & 기호를 사용한다.
GET, POST, PUT(또는 PATCH), DELETE 이 매서드들은 각각 조회, 추가, 갱신, 삭제와 관련이 있다. 메서드 설명은 MDN "HTTP 요청 메서드"를 참고하자.
