3.28 HTTP 네트워크

 

상품 정보 같은 리소스가 존재하는 곳과 리소스를 사용하는 앱을 분리시킨 것을 2티어 아키텍처, 또는 클라이언트-서버 아키텍처라고 부릅니다.
리소스를 사용하는 앱이 바로 "클라이언트", 리소스를 제공(serve)하는 곳은 "서버"라고 부릅니다.

 

일반적으로 서버는 리소스를 전달해 주는 역할만 담당합니다. 리소스를 저장하는 공간을 별도로 마련해 두는데 이 공간을 "데이터베이스"라고 부릅니다. 데이터베이스는 창고와 같은 역할을 합니다.

이처럼 기존 2티어 아키텍처에 데이터베이스가 추가된 형태를 3티어 아키텍처라고 부릅니다. 

 

웹 애플리케이션 아키텍처에서는 클라이언트와 서버가 서로 HTTP라는 프로토콜을 이용해서 서로 대화를 나눕니다. HTTP를 이용해 주고받는 메시지는 "HTTP 메시지"라고 부릅니다.

 

여기서는 잠깐 어떤 종류의 프로토콜이 있는지 한번 살펴보고 넘어갑니다. 지금 여기 있는 것을 다 외울 필요는 없습니다. 과제를 진행하는 데는 몰라도 상관없지만, 상식선에서 알아두면 좋습니다.

OSI 7 Layers는 컴퓨터공학과 네트워크에서 자주 등장하는 개념입니다. 해당 프로토콜이 어떤 계층(layer)에 속해있는지를 표시하고 있습니다. 이 역시 참고로 알아두세요.

 

API(Application Programming Interface)

서버는 클라이언트에게 리소스를 잘 활용할 수 있도록 API 인터페이스(interface)를 제공해 줘야 합니다. 

 

API는 Application Programming Interface의 약자이며, Interface의 사전적 의미는 "의사소통이 가능"하도록 만들어진 "접점"을 의미합니다. 이 의미에 따르면, 메뉴판도 인터페이스라고 볼 수 있습니다. 

다만 API는 앱이 요청할 수 있고 프로그래밍 가능한 인터페이스라는 점이 다릅니다. 

 

마찬가지로 서버가 리소스 전달을 위한 메뉴판, 즉 API를 구축해놓아야 클라이언트가 이를 활용할 수 있습니다. 

보통 인터넷에 있는 데이터를 요청할 때에는 HTTP라는 프로토콜을 사용하며, 주소(URL, URI)를 통해 접근할 수 있게 됩니다.

 

HTTP API 디자인에는 Best Practice가 존재합니다. 스타벅스 예제와는 다르게, 실제로 쓰일법한 API를 소개합니다. 사용자 관리 API인데요, URL 디자인은 비교적 단순하나 "메서드"라는 개념이 등장합니다.

HTTP 요청에는 메서드라는 것이 존재합니다. 앞서 스타벅스에서는 리소스를 그저 달라고(GET) 요청했지만, 사용자 관리 API에서는 사용자를 추가해 달라고(CREATE) 요청하거나, 지워달라고(DELETE) 요청할 수도 있습니다.

CRUD 각각의 행동과 일치하는 HTTP 메서드의 종류가 존재합니다.

 

이번 시간에서 여러분들이 기억해야 할 다섯 가지 메서드는 다음과 같습니다. GET, POST, PUT(또는 PATCH), DELETE 

각각 조회, 추가, 갱신, 삭제와 관련이 있습니다. 메서드 설명은 MDN "HTTP 요청 메서드"를 참고하세요.

이때 HTTP 메서드는 리소스를 이용하여, 하려는 행동에 맞게 적절하게 써야 한다는 점에 주의하세요. 만일 GET 요청을 했는데 갑자기 서버에서 리소스가 지워진다면 좋은 API 디자인이라고 볼 수 없습니다.