Client Server Architecture / Protocol / API

클라이언트 서버 아키텍처

쇼핑몰 어플리케이션을 인터넷 없이 이용하려고 한다면? 어플리케이션을 이용할 수 없다. 인터넷 어딘가에 존재하는 서버로부터 정보를 받아와야 하기 때문이다. 만약, 서버가 존재하지 않고, 어플리케이션 내부에 모든 정보를 저장하고 있다면, 쇼핑몰 상품의 가격 하나만 변동이 되어도 모든 정보를 앱 안에 담고있는 앱 자체를 전부 업데이트 해주어야 한다. 빈번한 업데이트가 필요한 경우 리소스가 존재하는 곳과 리소스를 사용하는 앱을 분리시키는 것이 유리하다. 

이러한 리소스가 존재하는 곳과 리소스를 사용하는 앱을 분리시킨 것을 2-Tier 아키텍처, 다른 말로 클라이언트-서버 아키텍처라고 부른다. 용어 뜻 그대로, 클라이언트(client, 손님)와 서버(server, 서빙하는 사람)의 역할을 한다. 클라이언트는 서버에게 리소스 요청을 하고, 서버는 리소스를 담아 응답을 한다. 클라이언트와 서버는 요청과 응답을 주고받는 관계이다.
일반적으로 서버는 리소스를 전달해주는 역할만 담당한다. 리소스를 저장하는 공간을 별도로 마련해 두는데 이 공간을 데이터베이스라고 한다. 2-Tier 아키텍처에 데이터베이스가 추가된 형태를 3-Tier 아키텍처라고 한다.

•  클라이언트: 유저와 전반적인 상호작용을 담당한다. 서버에 요청을 보내고 응답을 받는다.
• 서버: 클라이언트의 요청에 따라 적절한 응답을 클라이언트로 회신한다. 데이터베이스에 요청을 보내고 응답을 받는다.

클라이언트는 보통 플랫폼에 따라 구분된다. 브라우저를 통해 주로 이용하는 웹 플랫폼에서 클라이언트는 웹사이트 또는 웹 앱이라고 부른다. iOS나 안드로이드와 같은 스마트폰, 태블릿 플랫폼, 윈도우와 같은 데스크탑 플랫폼에서 이용하는 앱 역시 클라이언트이다.
 

---

프로토콜

통신 규약, 약속이다. 손님이 주문을 받는 사람에게 아무렇게나 외계어로 주문을 할 수 없듯이 주문을 하기 위해서 꼭 지켜야 하는 몇 가지 약속들이 존재한다. 웹 어플리케이션 아키텍처에서는 클라이언트와 서버가 서로 HTTP라는 프로토콜을 이용해서 서로 대화를 나눈다. HTTP를 이용해 주고받는 메세지를 HTTP 메세지라고 부른다.

스타벅스에서 커피 주문을 할 때 다양한 방법이 있다. 카운터로 찾아가거나 앱을 이용하거나 키오스크를 이용하는 것. 이것들 하나하나가 프로토콜이다. 규약이라는 측면에서는, 우리가 우체국에서 편지를 보낼 때, 보내는 사람과 받는 사람 작성하는 방법이 정해져 있다. 우편번호를 표기하지 않거나 우표를 안붙이면 우편은 제대로 전송되지 않는다. 우편을 보내기 위해 지켜야하는 규약이 있는 것이다. 

OSI 7계층 프로토콜 종류 예시

이처럼 프로토콜은 어떤 일을 처리하기 위해 지켜야 하는 규약이고, 종류가 다양하다. OSI 7 Layers에 따라 프로토콜들이 어떤 계층에 속해있는지 정해져 있다.

 

---

API(Application Programming Interface)

인터페이스는 '의사소통이 가능하도록 만들어진 접점'이다. 조금 추상적인데, 서로 다른 것이 이 접점을 통해 연결되는 것이다. API는 소통하는 방법이다. API를 구축한다는 것은 서로 다른 프로그램이 소통할 수 있는 방법, 요청과 응답을 주고받을 수 있는 방법을 마련한다는 것이다.

스타벅스에서 음료를 주문할 때 메뉴판을 보고 정해진 이름을 말하고 결제를 하면 진동벨을 주고 진동벨을 주면 주문한 음료가 나온다.
역전할머니맥주는 태블릿으로 주문을 하면 메뉴를 가져다준다.
스타벅스라는 세계와 역전할머니맥주라는 세계에서 요청하고 응답하는 방법이 마련되어 있다.

컴퓨터세계에서도 클라이언트가 서버에게 요청을 한다. 하지만 클라이언트는 서버개발자가 만든 서버가 어떻게 생겼는지 모르고 어떻게 동작하는지 모른다. 그래서 서버를 만들 때 서버에서 제공하는 리소스를 클라이언트가 어떻게 사용할 수 있는지 인터페이스를 만들어 제공해야 한다. 이 인터페이스가 API이다. 클라이언트가 서버의 리소스를 이용할 수 있도록 방법들을 마련해놓고(데이터를 볼 수 있도록, 데이터를 수정할 수 있도록) 매뉴얼인 API문서를 제공한다. 요청-응답 방법들을 구축하고 메뉴판처럼 ‘데이터를 읽어오고 싶을 땐 이렇게 하세요’, ’데이터를 삭제하고 싶을 땐 이렇게 하세요‘ 등을 기입해놓은 매뉴얼을 제공하는 것을 통틀어서 API라고 한다.

 

요청	메소드
Read	GET
Create	POST
Update	PUT, PATCH
Delete	DELETE

보통 인터넷에 있는 데이터를 요청할 때에는 HTTP라는 프로토콜을 사용하고 주소(URL, URI)를 통해 접근할 수 있다. 서버개발자는 HTTP 프로토콜과 주소를 기반으로 API를 디자인한다. URL을 디자인할 때 '메서드'라는 개념이 등장한다. 어떤 URL에 대해서 CRUD행동에 대한 메서드가 위와 같이 정해져있다. 

 

요청	URL 디자인	메소드
1번 사용자 정보 갱신	/users/1	PUT
1번 사용자 정보 삭제	/users/1	DELETE
1번 사용자 정보 조회	/users/1	GET

이렇게 같은 URL을 가져도 메소드별로 다른 요청을 처리한다. 위의 예시처럼 요청에 알맞은 메소드를 매칭시켜야 좋은 API 디자인이다. 가령, 정보 삭제 요청을 GET메소드에 매칭을 시키는 것은 바람직하지 않다.