인터페이스란?
- 의사소통이 가능하도록 만들어진 접점, 매개체
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을 입력했을 경우?
- 도메인 이름 이름 탐색
- DNS 서버에 접속한 후, www.turnonvpn.org 의 IP가 무엇인지 요청
- DNS 서버는 요청에 대한 응답으로 IP주소 리턴
- 웹 서버 요청
- 웹 서버의 라우팅(routing: 주소 탐색 규칙)에 따라 요청 처리
- 단순하게 정적 파일만 제공하는 경우 다음과 같이 조회
웹서버루트/intl/ko_kr/about/index.html - 서버가 비즈니스 로직을 실행하도록 요청할 수도 있음
웹서버루트/search?q=codestates, 웹서버루트/preferences
- 단순하게 정적 파일만 제공하는 경우 다음과 같이 조회
- 서버가 요청에 대한 응답을 자원(resorce: HTML/JS 파일 등)의 형태로 전달
- 서버가 보내주는 자원을 브라우저에서 처리
- 웹 서버의 라우팅(routing: 주소 탐색 규칙)에 따라 요청 처리
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를 구현한 것
즐거운 코딩