Client
카페를 예로 들었을 때 Client는 손님을 의미한다. 이 손님은 점원(server)에게 물품을 요청한다. 마찬가지로 사용자에게 보여지면서 사용자의 요청을 서버에 보내는 것이 클라이언트다.
클라이언트 앱은 사용자가 눈으로 보고 대면하기 때문에 프론트엔드 영역이라고 한다.
Server
카페를 예로 들었을 때, Server는 점원을 의미한다. 점원은 고객(client)의 요청에 응답한다. 정확히는 리소스를 전달해주는 역할, 리소스를 저장하는 공간은 데이터베이스라는 창고가 있다. 서버와 데이터베이스를 포괄해서 서버라고 부른다.
서버는 사용자의 눈에 보이지 않기 때문에 백엔드 영역이라고 한다.
Architectur
카페에서 점원이 서버(Server)고 손님이 클라이언트(Client)라고 한다면 Architectur는 카페 그 자체다.
리소스가 존재하는 곳과 리소스를 사용하는 앱을 분리시킨 것을 2-Tier아키텍처,
혹은 클라이언트-서버 아케텍처라고 한다.
여기에 데이터베이스가 추가된 형태를 3-Tier아키텍처라고 한다.
Protocol
프로토콜 : 서버와 클라이언트 간의 통신규약
클라이언트와 서버는 HTTP라는 프로토콜을 이용해서 대화를 나눕니다.
API
- API(Application Programming Interface) : 클라이언트가 서버에 자원을 요청 할 때, 서버가 어떻게 구성되어 있는지 알아야 정상적으로 요청을 받아 올 수 있다. 때문에 서버는 클라이언트가 리소스를 잘 활용할 수 있도록 인터페이스를 제공해야하는데 이 인터페이스가 API이다.
카페를 생각한다면 손님이 볼 수 있는 '메뉴판'이 API가 된다.
HTTP
메소드
HTTP요청시 메소드를 지정하여 리소스와 관련된 행동(CRUD)을 지정할 수 있다.
- Create :
POST(추가) - Read :
GET(조회) - Update :
PUTorPATCH(갱신) - Delete :
DELETE(삭제)
대표적으로 이 4가지 이 외에 다른 메서드들도 존재한다.
HEAD:GET과 동일한 응답을 요구하지만, 응답 본문을 포함하지 않는다.CONNECT: 목적 리소스로 식별되는 서버로의 터널을 맺는다.OPTIONS: 목적 리소스의 통신을 설정하는 데 사용된다.TRACE: 목적 리소스의 경로를 따라 메시지 loop-back 테스트를 한다.
메시지
메시지의 타입은 두가지가 있다.
request : 클라이언트가 서버로 전달해서 서버의 액션이 일어나게 하는 메시지
response : 요청에 대한 서버의 답변
두 구조는 서로 닮았으며, 다음과 같다.
1. 시작 줄에는 실행되어야 할 요청, 또는 요청 수행에 대한 성공 또는 실패가 기록(항상 한 줄로 끝)
2. 옵션으로 HTTP 헤더 세트가 들어간다. 요청에 대한 설명, 메시지 본문에 대한 설명 기록
3. 요청에 대한 모든 메타 정보가 전송되었을을 알리는 빈 줄이 삽입
4. 요청과 관련된 내용이 옵션으로 들억거나, 응답과 관련된 문서가 들어간다.(본문의 존재 유무는 첫줄고 HTTP헤더에 명시)
