클라이언트와 서버의 통신

김형주·2021년 4월 28일
2021.4.28(수)HTTP APITIL클라이언트서버통신
0
post-custom-banner

클라이언트-서버 통신

이전 글에서 클라이언트와 서버의 관계, 그리고 간단한 웹-서버 아키텍처에 관해 살펴보았다. 클라이언트는 서버에게 리소스나 데이터를 요청하고 서버는 리소스와 데이터를 제공하기도하고 관리하기도 한다는 것을 알았다. 그럼 요청-응답으로 이어지는 이 방식은 어떤 식으로 이루어지는걸까? 데이터를 달라고 요청하는 방법도, 데이터를 되돌려주는 방법도 정해져있지 않을까?

프로토콜(protocol)

통신 방법에 차이점이 생긴다면 데이터(리소스)를 교환하는 것에 문제가 생길 것이다. 나는 A방식으로 요청을 했는데 B방식으로 응답을 보내준다면 나는 해당 데이터를 어떻게 해야될지 고민해야할 것이고, 정상적으로 받기위한 방법을 항시 생각해봐야만 한다. 그래서 다른 컴퓨터 간(클라이언트-서버간)에 통신약속을 미리 해둔 것이 바로 프로토콜이다. 이 프로토콜이라는 것은 한 가지가 유일한 것이 아니라 사용되는 환경에 따라 규약을 정해두고 있다는 이야기다.

웹 애플리케이션 프로토콜 : HTTP

웹 애플리케이션 아키텍처에서 클라이언트와 서버간에 통신하기위해 만들어진 것이 HTTP 프로토콜이다. 클라이언트와 서버는 이를 기준으로 데이터를 요청하고, 제공한다.

HTTP이란?


HTTP(Hypertext Transfer Protocol)은 웹을 개발하는 사람이라면 모두 알아야만 하는 통신 프로토콜이다. 위에서 말했듯이 프로토콜은 "나는 이렇게 줄 테니, 너는 이렇게 받고 난 니가 준거 그렇게 받을게"처럼 약속을 정해두는 것이다. 웹에서 브라우저(클라이언트)와 서버가 데이터를 주고받기 위한 규약이 HTTP이다.

HTTP의 특징

HTTP는 상태가 없는(stateless) 프로토콜이다. 여기서 상태가 없다는 말은 데이터를 주고 받기 위한 각각의 데이터 요청이 서로 독립적으로 관리가 된다는 말이다. 내가 지금 만든 데이터 요청과 이 다음에 만들 데이터 요청간에 아무 관계가 없다는 이야기다. 예를 들어 클라이언트가 '데이터 요청' 상태가 되었다가, 받으면 '완료'상태로 세션이 생기는 것이 아니라 그때 그때 요청하면 그때 그때 요청을 개별적으로 처리하기때문에 주체에 대한 정보가 필요없다는 이야기다. 클라이언트가 받을 수 있는 상태인지 보낼 필요도 없고, 받은 상태인지 보내지 않아도 되서 진행절차상에 복잡한 일이 없다. 클라이언트가 요청하면 서버는 요청사항을 가지고 바로 응답을 보낸다. 성공했는지 실패했는지는 각각의 주체에서 개별적으로 확인된다.

내가 방금 데이터를 보냈어!, 내가 데이터를 받을 준비가 되었어!
이런게 하나도 필요없단 얘기다.

URL

URL(Uniform Resource Locators)는 이미 익숙하다. 주소로 많이 알고 있는데, 서버에 자원을 요청하기 위해 입력하는 영문 주소다. 사람입장에서 개별 PC의 IP 주소를 외우는 것보다 훨씬 쉽고 기억하기 쉽기 때문에 사용된다.

이 부분은 나중에 더 필요해지면 살펴보도록 해야겠다.
2021.4.28(수)

HTTP 요청 메소드

앞에서 본 URL을 이용하면 서버에 필요한 특정 리소스를 요청할 수 있따. 여기서 요청하는 데이터에 특정 동작을 수행하고 싶으면 어떻게 해야할까? HTTP 메소드를 사용하면 된다.

일반적으로 HTTP 요청메소드는 HTTP Verbs라고 불리며 아래와 같은 다양한 메소드를 가지고 있다.

HTTP 주요 메소드

  • GET
    서버에 존재하는 리소스에 대한 요청(주세요.)
  • POST
    서버에 새로운 리소스를 생성하도록 요청(줄게요.)
  • PUT
    서버에 존재하는 리소스를 변경하도록 요청(바꿔줘요.)
  • DELETE
    서버에 존재하는 리소스의 삭제를 요청(지워줘요.)

기타 메소드는 MDN문서를 통해서 확인하도록 하자.

API(Application Programming Interface)

API는 일종의 데이터 창구라고 이해하면 쉽다.

클라이언트에서 서버측에 데이터 제공을 요청,수정,변경을 요청할 때에 해당하는 창구로 가서 요청을 해야만 한다. 예를 들어, 나는 '헬스장 회원 정보'를 얻고 싶은데, '헬스장 운영비 관리'창구에 가서 요청하면 나는 원하는 데이터를 얻을 수 없다. 내가 원하는 데이터를 적절한 경로에 가서 요청해야하는데, 이때 Server API는 데이터가 저장된 자료창구 개념이다.

아래는 스타벅스 웹 페이지의 메뉴 API를 표현해본 것이다.

host
http://starbucks.com
/coffee/americano - 커피 중 아메리카노를 위한 창구
/coffee/coldbrew - 커피 중 콜드브루를 위한 창구
/foods/salmonsandwitch - 음식 중 연어 샌드위치를 위한 창구
/tea/remon - 차 중 레몬티를 위한 창구
/bread/honeybread - 빵 중 허니브레드를 위한 창구

즉 내가 원하는 리소스를 얻기 위해서는 적절한 API를 통해서 요청을 해야만 한다는 이야기다. API는 분류된 데이터들의 경로라고 볼 수 있고, 경로에 맞춰서 API를 작성해야 해당하는 창구에서 원하는 리소스를 끌어올 수 있다. 서버 입장에서는 클라이언트에서 적절한 경로를 통해서 리소스를 꺼내갈 수 있도록 API를 적절하게 구축하고 이를 위한 API문서를 작성해두어야 한다.

인터넷에 있는 데이터를 요청할 때에는 HTTP와 주소(URL,URI)를 통해 접근할 수 있다.

이런 식으로 URL을 디자인해서 사용자 관리 API를 구축할 수 있다. (API는 특별히 어떤 것이다, 라기보다는 클라이언트-서버간의 데이터 요청 과정에서 경로를 알아볼 수 있도록 해서 인터페이스를 구축하는 것의 의미를 가지고 있다.

각각의 데이터 창구마다 적절한 역할이 필요하고, HTTP verbs에 맞는 response를 낼 수 있도록 서버의 API를 설계하는 것이 중요하다.

profile
김형주
만물에 관심이 많은 잡학지식사전이자, 새로운 도전을 꿈꾸는 주니어 개발자 / 잡학지식에서 벗어나서 전문성을 가진 엔지니어로 거듭나자!
이전 포스트

Client와 Server

다음 포스트

Fetch API

post-custom-banner

0개의 댓글