[15. March] 클라이언트 - 서버 / TIL #1

 

클라이언트와 서버가 존재해야 앱이 정상적으로 가동될 수 있다.

 

---

리소스를 사용하는 앱 - 리소스가 존재하는 곳 : 클라이언트 - 서버 아키텍처

• 클라이언트 (손님) : 리소스를 사용하는 앱
  웹 앱, 스마트폰/태블릿/데스크탑 앱 등
• 서버 (점원) : 리소스가 존재하는 곳 
  파일 서버, 웹 서버, 메일 서버, 데이터베이스 서버 등
   + 데이터베이스 (창고) : 리소스를 저장하는 공간 ≫ 3티어 아키텍처
• 클라이언트, 서버 간 통신은 '요청'과 '응답'으로 구성된다.
• 프로토콜 : 통신 규약 / 같은 일을 하기 위해 '다양한 방법'이 존재할 수 있고, 각자의 프로토콜마다 지켜야 할 규약이 존재한다.
  OSI 7 Layers : 프로토콜 계층 별 종류
  
  
• 응용 계층

프로토콜 이름	설명
HTTP	웹에서 HTML, JSON등의 정보를 주고받는 프로토콜
HTTPS	HTTP에서 보안이 강화된 프로토콜
FTP	파일 전송 프로토콜
SMTP	메일을 전송하기 위한 프로토콜
SSH	CLI 환경의 원격 컴퓨터에 접속하기 위한 프로토콜
RDP	Windows 계열의 원격 컴퓨터에 접속하기 위한 프로토콜
WebSocket	실시간 통신, Push 등을 지원하는 프로토콜

 

• 전송 계층

프로토콜 이름	설명
TCP (양방향)	HTTP, FTP 통신의 등의 근간이 되는 인터넷 프로토콜
UDP (단방향)	단순하고 빠르지만, 신뢰성이 낮은 인터넷 프로토콜

---

• API (Application Programming Interface) : 서버가 클라이언트에게 리소스를 잘 활용할 수 있도록 제공하는 인터페이스
  - API가 UI와 다른 점은 API는 프로그래밍이 가능하고 앱이 요청할 수 있는 인터페이스라는 것이다.
  - API를 구축해 놓아야 클라이언트가 이를 활용할 수 있다.
• 이해하기 쉬운 API 예제 (feat. 커피 주문)
  - 호스트 : http://starbucks.com
  - *파라미터를 사용하기 위해 (?), (&) 기호를 사용하였다.

요청	URL 디자인 예제
아메리카노 한 잔 주세요	/coffee/americano
망고 프라푸치노 한 잔 주세요	/frappuccino/mango
콜드브루 두 잔 주세요	/coffee/coldbrew?quantity=2
아메리카노 두 잔 전부 헤이즐넛 시럽 넣어주세요	/coffee/americano?quantity=2&syrup=hazelnet

 

• 프론트엔드 : 클라이언트 앱 / 사용자가 눈으로 보고 대면하는 UI
• 백엔드 : 서버 앱 / 사용자 눈에 직접 보이지 않게 뒤에서 작동, API로 노출 / 사용자 인증 / 데이터베이스 / 시스템 설계

*파라미터(parameter) : 모델이나 함수에서 입력값을 결정하는 변수, 모델/함수 가 호출될 때, 입력값에 대한 처리를 수행하는데에 사용

---

• 사용자 관리 API : 메소드
  - HTTP 요청 시 메소드를 지정하여 리소스와 관련된 행동을 지정할 수 있다.

요청	URL 디자인	사용하는 메소드
모든 사용자 조회	/users	GET
새 사용자 추가	/users	POST
1번 사용자 정보 갱신	/users/1	PUT
1번 사용자 정보 삭제	/users/1	DELETE
1번 사용자 정보 조회	/users/1	GET

 

• CRUD (Create / Read / Update / Delete)
  - HTTP 메소드는 CRUD 행동에 따라 목적에 맞게 써야 한다.

요청	적절한 메소드
조회 (Read)	GET
추가 (Create)	POST
갱신 (Update)	PUT 또는 PATCH
삭제 (Delete)	DELETE