"메뉴판.."
배운 내용을 온전히 소화했든 그렇지 않든 시계는 돌아갑니다. 배워야 할 것들이 다가오죠. Promise 와 관한 내용이 너무 부실하다는 느낌이 있는데 이건 잠시 주말로 미뤄두도록 하고 오늘 배운 내용들을 정리해볼까 합니다.
Client-Server Architecture (a.k.a. 2-tier Architecture)
클라이언트-서버 아키텍처는 리소스를 요청하는 클라이언트와 리소스를 실제로 가지고 있는 서버로 나누어 분산하는 구조를 말합니다. 데이터가 실제로 구현되는 것은 클라이언트(웹 개발을 배우는 입장에서는 주로 웹브라우저가 여기에 해당하겠죠)이지만, 그 데이터는 실제로는 서버에 존재하고 클라이언트는 서버에 필요한 데이터를 요청해서 그때 그때 받아와 처리하는 것이죠.
스마트폰 게임을 예로 들자면 비행기모드를 걸고서도 동작하는 게임은 1-tier, 다시 말해서 설치를 통해 게임 실행에 필요한 모든 리소스를 스마트폰에 저장해두고 사용하는 것이 될 것이구요. 대부분의 모바일 게임은 최소한 2-tier 이상이 된다고 생각해볼 수 있겠습니다.
3-tier Architecture 는 2 티어에서 한 단계 더 나아가, 서버와 데이터베이스를 별도로 분리해 구축한 것을 말합니다. 클라이언트가 필요한 자료는 데이터베이스에 별도로 저장되어 있고, 서버가 중간자 역할을 감당하는 것이죠.
조금 더 정확한 설명은 위에 링크한 위키백과와, 여기를 확인해보시면 좋을 것 같습니다. 영어로 된 자료지만 그림도 잘 되어 있어 보기에 좋은 거 같습니다.
API (Application Programming Interface)
API 는 서버가 무엇을 어떻게 제공하는지를 클라이언트가 파악할 수 있도록 해둔 인터페이스입니다. 쉽게 말해서 메뉴판이라고도 할 수 있습니다. 처음 가는 식당에서도 주문을 할 수 있는 건 식당에서 제공하는 메뉴판이 있기 때문이죠.
클라이언트와 서버의 통신에 있어서 서버는 요청을 받아 처리하는 쪽입니다. 클라이언트가 요구하지도 않은 데이터를 전달하지 않는다는 거죠. 하지만 클라이언트가 서버에 무엇을 요청할 수 있는지조차 모른다면 둘 사이의 소통이 불가능합니다. 따라서 서버는 API 문서를 통해 어떻게 자기들이 가진 리소스를 활용하고 받을 수 있는지를 안내합니다.
HTTP status codes
공부하다 HTTP 상태 코드를 간단하게 정리해 둔 자료를 보게 되었는데요. 흥미로워서 가져와봤습니다.
HTTP status codes
1xx: hold on
2xx: here you go
3xx: go away
4xx: you screwed up
5xx: I screwed up
공식 문서의 전체 상태 코드를 위 자료와 비교해보면 조금 더 쉽게 이해가 가능할 것 같네요.
주말동안 배운 것들 조금 더 잘 정리해서(특히 프로미스..) 블로깅 해보려고 합니다. 주말이 뭔가요..?
