클라이언트와 서버의 통신
클라이언트와 서버 간의 통신은 요청과 응답으로 구성된다
요청이 있어야만 응답이 온다
간혹 서버에서 일방적으로 클라이언트에 정보를 전달하는 적이 있을텐데 어떤 경우일까?
프로토콜(Protocol)
프로토콜은 통신 규약, 즉 약속이다.
손님이 주문을 받는 사람에게 대뜸 찾아가, 외계어로 주문을 할 수 없듯, 주문을 하기 위해서는 꼭 지켜야만 하는 약속이 몇가지 존재한다.
웹 애플리케이션 프로토콜: HTTP
웹 애플리케이션 아키텍처 에서는 클라이언트와 서버가 서로 HTTP 라는 프로토콜을 이용해서 서로 대화를 나눈다.
HTTP를 이용해 주고받는 메시지는 "HTTP 메시지"
라고 부른다.
프로토콜 Case Study: 커피 주문
이러한 방법 하나하나 전부 프로토콜이다.
같은 일을 하기 위해 "다양한 방법"이 존재할 수 있는 것이다.
프로토콜 Case Study: 우편
"규약"이라는 측면에서 프로토콜을 이해해보자면
우편을 보낼 때에 수신자에 대한 아무런 표기가 없다면, 이 전송 요청은 갈길을 잃고 말 것이다.
그리고 수진자를 적어도 우표를 안붙이면 마찬가지로 반송이 될 것이다.
이는 "우편 전송"이라는 행동을 하기 위해 반드시 지켜야 하는 규약이 있음을 의미한다.
프로토콜은 각자의 프로토콜 마다 지켜야 하는 규약이 존재한다.
MDN에서의 "HTTP 메시지" 라는 항목을 잘 살펴보면, HTTP 만의 규칙이 있음을 발견할 수 있다.
주요 프로토콜
상식선에서 알아두는 것이 좋음
API
손님이 메뉴를 주문하려면, 메뉴판을 보고 주문해야한다.
컴퓨터에게 요청할 때에는, 정확한 주문 방법을 따라 요청해야한다.
서버가 어떻게 구성되어 있는지 모른다면, 클라이언트는 어떻게 자원을 확인할 수 있을까?
위에 대한 정답이 바로 API(Application Programming Interface)이다.
서버는 클라이언트에게 리소스를 잘 활용할 수 있도록 인터페이스(interface)를 제공해 줘야 한다.
이것을 API라고 한다.
서버에는 마치 식당에서 메뉴판을 제공하듯,
리소스를 잘 활용할 수 있도록 API를 제공해야 한다.
API는 Application Programming Interface의 약자이며, interface의 사전적의미는
"의사소통이 가능" 하도록 만들어진 "접점"을 의미한다.
이 의미에 따르면, 메뉴판도 인터페이스 라고 볼 수 있다.
다만 API는, 앱이 요청할 수 있고 프로그래밍 가능한 인터페이스라는 점이 다르다.
API Case Study: 커피 주문
API는 메뉴판과도 같다.
메뉴판은 해당 커피샵에서 주문 가능한 메뉴를 안내해준다.
클라이언트가 엉뚱한 메뉴를 시키지 않도록 한다.
메뉴판을 설계해놓았기 때문에, 우리는 이에 맞게
적절한 요청을 할 수 있다.
마찬가지로 서버는 리소스 전달을 위한 메뉴판, 즉 API 문서를 작성해야 클라이언트가 이를 활용할 수 있다.
보통 인터넷에 있는 데이터를 요청할 때에는 HTTP 프로토콜을 사용하며, 주소(URL, URI)를 통해 접근할 수 있다.
파라미터를 사용하기 위해 물음표(?)와 & 기호를 사용하는 것을 참고
좋은 레퍼런스
HTTP API 디자인을 잘 하는 방법
사용자 관리 API 인데, URL 디자인은 비교적 단순하나 "메소드"라는 개념이 등장한다.
사용자 관리 API 에서는 사용자를 추가해 달라고 (CREATE) 요청하거나 지워달라고 (DELETE) 요청할 수도 있다.
마치 CRUD 행동과 비슷하다.
CRUD 각각의 행동과 일치하는 HTTP 메소드의 종류가 존재한다.
"HTTP 요청 메소드" MDN 참고(설명)
이때 HTTP 메소드는 리소스를 이용해 하려는 행동에 맞게 적절하게 써야 한다.
만일 GET 요청을 했는데, 갑자기 서버에 리소스가 지워진다면,
좋은 API 디자인이라고 볼 수 없다.
