API & UI & Client-Server Model

인터페이스란?
- 의사소통이 가능하도록 만들어진 접점, 매개체

API(Application Programming Interface)

---

• 프로그래밍 되어 있는 애플리케이션과의 의사소통 가능한 매개체

UI(User Interface)

---

• 유저와 의사소통 가능한 매개체

Web Architecture

---

Brower

• html, css, js 로 작성한 코드를 내부 엔진으로 해독하여 사용자가 쉽게 이해할 수 있는 형태의 컨텐츠로 보여주는 역할(브라우저에 내장되어 있는 엔진을 이용해서)

client

• 터미널의 역할을 수행하는 컴퓨터 (웹 브라우저는 대표적인 터미널)
• 사용자 입력을 주로 수행
• 서버에 대한 응답을 화면에 표시
• 현대의 복잡한 시스템은 클라이언트이면서 서버의 역할을 동시에 수행하는 경우도 있다.

server

• 서비스를 제공하는 컴퓨터로, 다수의 클라이언트 컴퓨터의 요청을 처리하기 위해 존재
• Web Server, File Server 등
• 웹 페이지 지원이나, 공유 데이터의 처리 및 저장 등의 비즈니스 로직을 주로 수행

api

• 클라이언트와 서버가 상호작용하는데 서버 자원을 잘 가져다 쓸 수 있게 만들어 놓은 인터페이스(메뉴판)
• 서버 자원에 접근하기 위해 서버와 상호작용하는 방법들을 정리해둔 규칙이라고 보면 된다.

HTTP : 클라이언트와 서버가 통신할 때 사용하는 통신 규약

• 작동방식 : 항상 요청과 응답으로 이루어 진다.

  • 구성 : 기본적으로 헤더와 바디를 가진다.

    • 헤더 : 어디에서 보내는 요청인가, 컨텐츠 타입은 무엇인가, 어떤 클라이언트를 이용해 보냈는가
    • 바디 : 데이터를 보내는 공간

  • HTTP/1.1의 경우 요청와 응답은 Start/Status line, Header 그리고 Body로 이루어져 있다

  • 속성 : stateless, connectionless

    • stateless : HTTP는 특정 상태를 담고 있지 않기 때문에 이전 요청이나 다음 요청을 기억하지 않는다.
    • connectionless : 연결 상태를 유지시키지 않는다. 즉,응답이 완료가 되면 클라이언트와 서버의 연결이 끊어지는 특징.

  • 요청 메소드

    • GET: 서버에 자원을 요청
    • POST: 서버에 자원을 제출. 서버 상태의 변화를 일으킨다.
    • PUT: 서버의 자원을 수정
    • PATCH : 서버의 데이터 일부분 수정
    • DELETE: 서버의 자원을 제거

  • 응답 상태 코드

    • 200: 요청 성공
    • 304: 요청에 대한 응답이 수정되지 않음
    • 4xx: 404: not found, 403: forbidden, 400: bad request
    • 5xx: 500: internet server Error, 502: bad gateway

Communication Between Client and Server

• 클라이언트와 서버는 프로토콜에 따라 메시지를 교환
• 클라이언트는 서버가 어떤 식으로 요청을 처리하는지에 대해선 구체적으로 알 필요없이, 추상화된 인터페이스를 바탕으로 원격 서버에 요청(RPC: remote procedure call)을 하고, 응답에 대해 적절한 형태로 화면에 표시

Messaging patterns

• Request-Response
  • 대표적으로 HTTP 프로토콜이 사용하는 메시징 패턴
  • 보통 동기적으로 작동하며, 연결이 열리면 응답이 전달될 때까지 기다리거나, timeout 전달
• Publish-Subscribe
  • 수신자가 지정되지 않은 대신, 메시지가 발행되면 구독을 신청한 수신자에게 일괄적으로 전달
  • 비동기 메시징이며, 메시지 브로커 또는 Event bus라고 불리는 것이 중간에 구현되어야 함.
• Push technology(Server push)
  • Publish-Subscribe 모델의 일종
  • 전송 요청이 클라이언트로부터 시작되지 않음.
  • HTTP/2에서 Server push라는 이름으로 구현
  • WebSocket 프로토콜을 이용해 구현 가능

URL(uniform resource locators)

웹에서 정해진 유일한 자원의 주소

http://www.example.com:80/path/to/myfile.html?key1=value1&key2=value2#SomewhereInTheDocument

• http
  • 어떤 프로토콜을 사용해야 하는지 나타낸다.
  • 사용하고 싶은 우편 서비스
• www.example.com
  • 도메인 이름. 어떤 웹 서버가 요구되는 것인지를 가리킨다.
  • 우편을 전달하고자 하는 도시나 마을
• 80
  • 포트. 웹 서버에서 자원을 접근하기 위해 사용하는 관문 개념
  • 만약 웹서버가 자원의 접근 하기 위해 표준 HTTP 포트 (HTTP를 위한 80, HTTPS를 위한 443)를 사용한다면, 포트 번호는 보통 생략합니다. 그렇지 않으면 포트 번호는 필수.
  • 우편 번호
• /path/to/myfile.html
  • 웹 서버에서 자원의 경로를 나타낸다.
  • endpoints 라고도 부른다.
  • 메일이 전달되어야 하는 건물
• ?key1=value1&key2=value2
  • 웹 서버에 제공하는 추가 파라미터, & 기호로 구분된 키/값을 제공한다.
  • 건물 번호와 같은 정보
• #SomewhereInTheDocument
  • 자원 자체의 다른 부분에 대한 anchor(닻), 자원 자체의 다른 부분에 대한 anchor(닻)
  • 우편을 받을 실제 사람

HTTP & REST

---

브라우저에 URL을 입력했을 경우?

1. 도메인 이름 이름 탐색
   1. DNS 서버에 접속한 후, www.turnonvpn.org 의 IP가 무엇인지 요청
   2. DNS 서버는 요청에 대한 응답으로 IP주소 리턴
2. 웹 서버 요청
   1. 웹 서버의 라우팅(routing: 주소 탐색 규칙)에 따라 요청 처리
      • 단순하게 정적 파일만 제공하는 경우 다음과 같이 조회
        웹서버루트/intl/ko_kr/about/index.html
      • 서버가 비즈니스 로직을 실행하도록 요청할 수도 있음
        웹서버루트/search?q=codestates, 웹서버루트/preferences
   2. 서버가 요청에 대한 응답을 자원(resorce: HTML/JS 파일 등)의 형태로 전달
   3. 서버가 보내주는 자원을 브라우저에서 처리

RESTFUL API

REST 패턴을 따르는 인터페이스를 말한다.

• REST(Representational State Transfer)
  • API 디자인에 있어서 HTTP 프로토콜을 의도에 맞게 사용하도록 정의된 아키텍쳐 스타일
  • HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고, HTTP Method(POST, GET, PUT, DELETE)를 통해 해당 자원에 대한 CRUD Operation을 적용하는 것을 의미한다.
• 대표적인 원칙
  • URI는 정보의 자원을 표현해야한다.
  • 자원에 대한 행위는 HTTP Method로 표현해야 한다.
• REST 스타일을 준수했을 때 RESTful 하다고 부른다.
• REST API : REST 를 기반으로 API를 구현한 것