#8 (Interaction with Server)

Angelo·2020년 7월 1일
[Javascript] 이머시브 코스 학습 정리
0

Codestates  IM Javascript

목록 보기
7/13
post-thumbnail

Web Architecture

  • API (Application Programming Interface)
    -> 프로그래밍 되어 있는 서버 애플리케이션과 의사소통 가능한 매개체

  • UI (User Interface)
    -> 유저가 웹서비스를 사용하게 끔 의사소통 가능한 매개체

  • Interface
    -> 사물 간 또는 사물과 인간간의 의사소통이 가능 하도록 만들어진 물리적, 가상적 매개체(접점)를 의미한다.

  • 클라이언트는 서버에 http를 활용해서 리소스 요청과 응답
    클라이언트 서버 프로토콜(웹브라우저)

  • 서버는 Db에 리소스 저장 또는 클라이언트에 응답

Browser

  • 브라우저의 주요 기능 :
    사용자가 선택한 자원을 서버에 요청하고 브라우저에 표시하는것.
    컴퓨터는 2진수만 알아 듣는다. 브라우저 덕분에 HTML, CSS, Javascript를 사용 가능.
    HTML과 CSS 명세에 따라 HTMl 파일을 해석해서 표시.

브라우저의 기본 구조 :

  1. 사용자 인터페이스 : 주소 표시줄, 이전-다음 버튼, 북마크 메뉴 등. 요청한 페이지를 보여주는 창을 제외한 나머지 모든 부분

  2. 브라우저 엔진 : 사용자 인터페이스와 렌더링 엔진 사이의 동작을 제어

  3. 렌더링 엔진 : 요청한 콘텐츠를 표시. HTML을 요청하면 HTML과 CSS를 파싱하여 화면에 표시

  4. 통신 : HTTP 요청과 같은 네트워크 호출에 사용됨 (플랫폼 독립적 인터페이스)

  5. UI 백엔드 : 콤보 박스와 창 같은 기본적인 장치를 그림.(OS사용자 인터페이스)

  6. 자바스크립트 해석기 : 자바스크립트 코드를 해석하고 실행

  7. 자료 저장소 : 자료를 저장하는 계층. 모든 종류의 자원을 하드 디스크에 저장.

Server

  • 서버는 일반적으로 클라이언트라고 불리는 사용자에게 서비스를 제공하는 소프트웨어 또는 하드웨어.
    클라이언트의 요청을 받으면 리소스를 바탕으로 응답한다.

  1. 하드웨어 측면에서 보면, 웹 서버는 웹 서버 소프트웨어 및 웹 사이트 구성 요소 파일(HTML 문서, 이미지, CSS & Javascript 파일)을 저장하는 컴퓨터이다. 인터넷에 연결되어 있으며 웹에 연결된 다른 장치와의 물리적 데이터 교환을 지원한다.

  2. 소프트웨어 측면에서 보면, 웹 사용자가 최소한 HTTP 서버로 호스팅 된 파일에 액세스 하는 방법을 제어하는 여러 부분이 포함 되어 있다. HTTP 서버는 URL 및 HTTP를 이해하는 소프트웨어이다. 웹사이트 주소를 입력해서 접속하면 웹사이트의 데이터를 전달해준다.

  3. HTTP 트랜잭션 해부

  • 서버 만들기

API

Application Programming Interface

  • 프로그래밍 되어 있는 소프트 웨어 프로그램(서버 애플리케이션)과 의사소통 가능한 매개체. 서버 자원을 잘 가져다 쓸 수 있게 만들어 놓은 Interface. 서버가 API를 제공해줘야 클라이언트가 데이터베이스에 있는 자료를 알게 되고 활용 할 수 있다.

예를 들어 :
Twitter API는 가장 최근 트윗을 웹페이지에서 보여주는 등, 사용자의 트위터 계정에서 정보를 반환하는데 씀
Web Animations API는 이미지를 여기저기 움직이거나 회전 시키는 등, 웹페이지의 일부를 움직이도록 하는데 씀

HTTP

HyperText Transfer Protocol

  • 클라이언트와 서버가 통신하기 위해 HTTP라는 규약 또는 규칙을 지켜서 통신을 한다.

1. 작동 방식 : 항상 요청과 응답으로 이루어 진다. 클라이언트가 메세지를 달라고 요청을 하면 서버가 메시지를 전달해준다. 없으면 없다고 응답을 준다.
서버가 요청에 대한 응답을 안주면 오류가 난다.

2. 구성 : HTTP 요청은 HEADER와 BODY로 나뉘어 진다.

Header는 어디서 보내는 요청인가(origin), 컨텐츠 타입은 무엇인가(content-type), 어떤 클라이언트를 이용해 보냈는가(user-agent)
헤더의 프로퍼티는 이름-값(Name-value) 쌍으로 설정되며 콜론으로 구분된텍스트다.

Body는 서버의 데이터를 보내기 위한 공간으로 활용. 각 method가 body를 가질 수도 안가질 수도 있다.

  • 넓게 보면 본문은 두가지 종류로 나뉜다.

단일-리소스 본문(single-resource bodies): 헤더 두 개(Content-Type와 Content-Length)로 정의된 단일 파일로 구성된다.

다중-리소스 본문(multiple-resource bodies): 멀티파트 본문으로 구성되는 다중 리소스 본문에서는 파트마다 다른 정보를 지니게 된다. 보통 HTML 폼과 관련이 있다.

HTTP 응답도 HEADER와 BODY로 나뉘어 진다.

3. 속성 :

예를 들어: 클라이언트가 서버에게 '커피를 달라'고 해서 커피를 받았는데, 이후에 '어떻게 마셔야되?' 라는 다른 요청을 하면 서버는 무엇을 마시는 방법을 알고 싶은건지 요청에 명시가 안되어 있어서 뭔지 모른다.

  • stateless : 무상태성. HTTP의 각 요청은 모두 독립적이다. state라는 것이 없다. 서버는 클라이언트의 상태를 기억 못한다.

  • connectionless : 무연결성. HTTP는 한번의 요청에는 한번의 응답을 한다.
    응답 이후에는 연결이 끊기기 때문에, 더이상 응답을 할 수 없다.

  1. HTTP method :
  • GET : HTTP 서버에 데이터 검색을 요청한다. 특정리소스를 가져오도록 요청
  • POST : HTTP 서버에 데이터를 생성, 수정과 삭제를 요청한다. 데이터를 서버로 제출하는 용도로 사용, 서버 상태의 변화를 일으킴
  • PUT : HTTP 서버에 데이터 저장(생성, 수정)을 요청한다. POST의 일부와 비슷한 개념, 연속적인 요청시에도 같은 효과를 가져온다. 기존 데이터를 교체하는 용도로 쓰일 수 있다.
  • DELETe : HTTP 서버에 데이터 삭제를 요청. POST의 일부와 비슷한 개념, 리소스의 삭제를 요청할 때 사용

4. 상태 코드 :

Ajax

Asynchronous Javascript And XML(EXtensible Markup Language)

  • AJAX는 전체 페이지가 다시 로드 되지 않고 일부분만 업데이트하는 좀 더 복잡한 웹페이지를 만들 수 있게 해준다.

  • 또한 AJAX를 사용하면 웹페이지 일부가 리로드 되는 동안에도 코드가 계속 실행되어 비동기식으로 작업할 수 있다.

  • 단순한 웹페이지가 아닌 웹 어플이 등장(Javascript와 DOM 이용)

  • 서버와 자유롭게 통신할 수 있고, 페이지 깜빡임 없이 seamless 하게 작동하는 (XMLHttpRequest(XHR) API 등장)

  • 가독성이 떨어지고 복잡한 XMLHttpRequest API 를 보다 쓰기 쉽게하기 위해 JQuery가 나왔고 또 다시 쉽게 쓰기 위해 표준 API로 현재 fetch 라는 API가 등장.

Fetch API

  • fetch function을 get 서버에서 자원을 가져오기 위해 쓴다.

  • 비동기 네트워크 통신을 알기 쉽게 기술 할 수 있다.

  • fetch()로 부터 반환되는 Promise 객체는 HTTP error 상태를 reject하지 않는다. 대신 ok 상태가 false인 resolve가 반환되며, 네트워크 장애나 요청이 완료되지 못한 상태에는 reject가 반환된다.

  • 기본적인 fetch 구문 

fetch('http://example.com/movies.json')
  .then(function(response) {
    return response.json();
  })
  .then(function(myJson) {
    console.log(JSON.stringify(myJson));
  });

  • 네트워크에서 JSON 파일을 가져와 콘솔에 인쇄. 간단한 fetch() 사용 흐름은 인수 한개(가져올 자원의 경로)를 가져오고 응답을 포함하는 약속(response 개체)를 반환 하는것.

  • response 객체로부터 자료를 가져오기 위해서는 json() 메서드를 사용해야 한다.

CORS

  • Cross Origin Resource Sharing, cross origin에서 리소스(서버자원)을 요청하여 사용한다.

  • same origin이 아니라 cross origin을 요청해야한다.

  • 원래는 브라우저에서 크로스 도메인 요청은 기본적으로 제한 되어있다(보안상의 이유). 개발자들이 웹 애플리케이션 고도화를 위해 개선 요청. 결국엔 서버가 Allow한 범위 내에서 cross origin 요청 허용.

-> 모든 도메인(*)을 허용한다
-> 메소드는 GET, POST, PUT, DELETE, OPTIONS만 허용한다.
-> 헤더에는 content-type과 accept만 쓸 수 있다.
-> preflight request는 10초까지 허용 된다. 

const defaultCorsHeaders = {
  'access-control-allow-origin' : '*',
  'access-control-allow-methods' : 'GET, POST, PUT, DELETE, OPTIONS',
  'access-control-allow-headers' : 'content-type, accept',
  'access-control-allow-max-age' : 10 
};
  • OPTIONS -> preflight request

Client가 POST 요청하기전 OPTIONS 메소드를 통해 서버에 물어본다.
서버에서 Allow하는 조건들을 다 맞추고 있는가?
(사전에 서버에 확인 하는 요청)

RESTful API

  • REpresentational State Transfer (표현 상태 전달)

  • 웹 서비스를 만드는데 사용되는 제약(constraint) 모음

  • 어떤 조건을 따르면서 API를 만들어보자는 전제
  1. (HTTP)Client-Server : 서버와 무관하게 클라이언트가 작성되어야 한다
  2. (HTTP)Stateless : 하나의 요청에 모든 정보를 다 알려줘야 한다 (ex. 서버는 앞뒤 문맥을 기억하지 못함)
  3. (HTTP)Cacheable : 특정 정보들을 미리 서버에 저장할 수 있게 해야 된다
  4. Uniform interface : 같은 스타일의 API 동일한 인터페이스로 만들어져
    있어서 쉽게 알 수 있어야 한다
  5. (HTTP)Layered system : 서버가 어떤 방식으로 구성되어 있고 어떤 방식으로 돌아가는지 클라이언트는 몰라도 된다
  6. (JavaScript)Code on demand : 자바스크립트 같은 코드를 내려줄 수 있어야 한다
  • REST에서 정보의 가장 핵심적인 추상화는 리소스다. 이름 붙일 수 있는 정보면 어떤 것이든 리소스가 될 수 있다.

Uniform Interface

유니폼 인터페이스 조건:

  1. Identification of resources : 리소스를 식별할 수 있어야 한다

  2. manipulation of resources through representation : 리소스를 표현에 의해서 조작할 수 있어야 한다

  3. self-descriptive messages : 어떤 정보를 조작을 하기 위해 보내는 메세지에는 거기에 필요한 모든 정보가 들어 있어야 한다

  4. HATEOAS: 링크가 있어야 한다

  • simple guide line :
  1. 리소스를 나타내는 데 명사(nouns)를 사용하라
  2. 일관성이 핵심
  3. CRUD 기능 이름은 URI에 사용하지 마라
  4. filter가 필요하면 query component를 사용하라

Express . 미들웨어 작성 필요

profile
Angelo
나만의 학습 노트
이전 포스트

#7 (Asynchronous & Promise)

다음 포스트

#10 (Module & CommonJS)

0개의 댓글