Client Server Architecture

2Tire Architecture

Case study: shopping app

• 인터넷과 연결 없이, 앱을 구동하였을 때에 실행이 안되는 이유
  • 상품 정보를 서버에서 받아오기 때문 (인터넷 x, server가 죽었다)
• if, 상품 정보가 앱에 전부 저장된 경우, 위의 경우에도 앱은 가동
  • but, 상품이 추가 또는 정보가 변경 될 때마다 앱을 업데이트 해야함
  • 결제도 불가능, 은행 서버와 연결이 필요
  • 결국, 제품 카탈로그 수준의 앱이 될 것
• 리소스(상품 정보)와 앱을 분리시킨 것을 2티어 아키텍쳐, 클라이언트-서버 아키텍쳐
  • client(손님)-server(서빙 직원)의 관계, 물품을 (요청)-리소스를 담아 (응답)

구동 방식

• client: data request - server: response(err or data)
• 요청이 없는 응답은 없음, 요청이 선행되야, 응답을 줌
• client - server - database 의 저장소가 추가된 형태를, 3티어 아키텍쳐
• client를 다루는 프론트엔드, server-database를 다루는 벡엔드\
• client: website, app(mobile), app(desktop)
• server: web server, file server, mail server, database server...

Cilent-Server API

• basic: client(request) -> server(response)의 구조
• especially, server에서 일방적으로 client에 정보를 전달하는 경우 발생(cookie)
• protocol(프로토콜): 통신 규약, 서버에 맞는 프로토콜로 요청을 해야함
• HTTP: Web application protocol, HTTP message

Case study

• starbucks에서 커피를 주문하는 경우
  • protocol 1: counter에서 직접 주문하는 경우
  • protocol 2: mobile app으로 siren order하는 경우
  • protocol 3: kiosk에서 주문하는 경우
  • API: prtocol에 각각 menu판을 제공해야 함
  • /coffee/americano?quantity=2&syrup=hazelnut
  • coffee중에 americano 주시구요(요청), 2잔 주시고 시럽은 헤이즐넛이요(파라미터)
• 우편을 통한 편지 보내기
  • 우편 봉투에 규약에 따른 올바른 표기를 해야 우편물이 제대로 발송될 것
  • 보내는 사람은 좌측 상단에, 받는 사람은 우측 하단에, 우편 번호는 형식에 맞게 기재 등등

API

• API(Application Programming Interface)
• server는, client에게 올바른 resource 요청을 하기 위한 interface를 제공해야 함
• 인터넷에 있는 데이터를 요청, HTTP라는 프로토콜을 사용, 주소(URL, URI)를 통해 접근
  URL design reference

Case study: 사용자 관리 API

• HTTP API 디자인의 Best Practice
• CRUD(Create, Read, Update, Delete)
• Create: POST/ Read: GET/ Update: PUT or PATCH/ Delete: DELETE
  HTTP 요청 메서드(MDN)
• 모든 사용자 조회 : /users : GET
• 새 사용자 추가 : /users : POST
• 1번 사용자 정보 갱신 : /users/1 : PUT
• 1번 사용자 정보 조회 : /users/1 : GET
• 1번 사용자 정보 삭제 : /users/1 : DELETE