🖥️클라이언트-서버 모델

리소스를 사용하는 앱과 존재하는 곳을 분리한 모델

• 2-tier 아키텍쳐
• 클라이언트 : 웹/앱을 이용하는 사용자 (웹 브라우저를 통해 원하는 데이터를 서버에 요청)
• 서버 : 클라이언트의 요청을 처리해서 응답하게 됨
  

📢HTTP

요청/응답 구조로 이루어짐

• HTTP request 구조

  1. Start line

     • HTTP Method : 요청이 의도한 action(GET, POST, DELETE, PUT …)

       • GET : 서버로부터 데이터 취득
       • POST : 서버에 데이터 추가, 작성
       • PUT : 서버의 데이터 갱신, 작성
       • DELETE : 서버의 데이터 삭제
       • HEAD : 서버 리소스의 헤더
       • OPTIONS : 리소스가 지원하고 있는 메소드의 취득
       • PATCH : 리소스 일부분 수정
       • CONNECT : 프록시 동작의 터널 접속 변경

     • Request Target : request가 전송되는 목표 주소
     • HTTP Version

  2. Headers

     request에 대한 추가 정보를 담고 있는 부분
     Key:Value 형태

     • general header : 요청/응답 모두 적용. 바디에서 전송되는 데이터와 무관
     • request header : 페치될 리소스나 클라이언트 자체에 대한 정보를 포함(보내는 메세지)
     • response header : 위치 또는 서버 자체에 대한 정보 등 응답에 대한 부가적인 정보 포함(받은 메세지)
       • entity header : entity 바디에 대한 정보 포함

  3. body

     HTTP Request가 전송하는 데이터를 담고 있는 부분

     • 데이터가 없으면 비어있음
     • POST 요청일 경우 HTML 폼 데이터가 포함
• Response Message
  1. Status Line
     • HTTP Response의 상태 간략히 나타냄
     • HTTP version, Status Code, Status Text
  2. headers
     • Request와 동일
  3. body
     • Request와 동일
• 상태 코드
  • 클라이언트가 보낸 HTTP 요청에 대한 서버의 응답 코드
  • 요청의 성공/실패 여부 판단

    100 : 조건부 응답 → 요청이 수신되어 처리 중을 의미
    200~206 : 요청을 정상적으로 처리함
    300~308 : 요청 완료를 위해 추가 작업 조치가 필요
    400~429 : 클라이언트 오류로 인해 서버가 요청을 처리할 수 없음
    500~504 : 서버 오류로 인해 서버가 정상 요청을 처리하지 못함

☁️REST API

• Representational State Transfer API
  → REST의 원리를 따르는 API
• REST : HTTP URI를 통해 자원을 명시하고 HTTP Method를 통해 해당 자원에 대한 CRUD Operation(생성, 조회, 수정, 삭제)을 적용하는 것

구성 요소

1. 자원 → HTTP URI
2. 자원에 대한 행위 → HTTP Method
3. 자원에 대한 행위의 내용 → HTTP Message Pay Load

장점

• HTTP 프로토콜 인프라 그대로 사용하므로 별도의 인프라 구축 필요 없음
• 의도하는 바를 쉽게 파악할 수 있다
• 서버와 클라이언트의 역할을 명확하게 분리한다
• 서비스 디자인 문제를 최소화한다
• HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용 가능

단점

• 표준이 존재하지 않아 정의해야 한다
• HTTP Method 형태가 제한적이다
• 전문성이 요구된다
• 구형 브라우저에서는 호환되지 않는다