[1주차] [1일차] 나만의 스토리 설계 웹 페이지 설계 (2)

챕터 2-1 : 서버란

 

학습 목표

● 서버란 무엇인지 설명할 수 있다.

● 서버의 역할 (웹 호스팅, API)에 대해서 설명할 수 있다.

 

서버 : 클라이언트(홀)가 주문 (요청)을 보내는 대상

● 서버라는 단어는 IT 세게에서 두 가지 의미로 사용됩니다.

- 하드웨어 서버

- 소프트웨어

 

● 백엔드 개발자 : 소프드 웨어 서버를 만드는 사람

 

하드웨어

● 컴퓨터를 구성하는 물리적인 부품을 말함

● 눈으로 보고 만질 수 있는 모든 장치를 말함 ( 컴퓨터 그 자체 ).

 

1-1 특징

● 항상 켜져있어야 한다. 손님 (클라이언트)가 새벽 3시에 주문해도 받아야 하기 때문

● 고정 ip 주소를 사용해야 된다.

 

1-2 분류

● 거대한 데이터 센터의 여러 대의 컴퓨터도 서버가 될 수 있음.

● 클라우드 서비스에 빌린 가상 컴퓨터도 서버가 될 수 있음.

 

[ 클라우드 서비스란? ] : AWS, Google, Oracle, Naver와 같은 대형 소프트 웨어 서버가 필요한 회사에 대여해 주는 가상 컴퓨터 서비스

 

소프트웨어로서의 서버

- 실제 백엔드 개발자가 만드는 서버로 하드웨어 서버라는 컴퓨터 안에서 실행되는 프로그램을 말한다.

- 클라이언트의 요청을 듣고 그에 맞는 응답을 하도록 설계되어 있음.

 

● 컴퓨터(하드웨어)에는 수만 개의 포트(Port)가 있습니다.

● 서버 프로그램 (소프트웨어)는 이 중 특정 문을 열고 귀를 기울인다.

○ HTTP ( Port 80 ) : 일반 주면을 받는 문

○ HTTPS ( Port 443 ) : 보안(암호화) 주문을 받는 문

 

웹 파일 제공

- 파일들을 전 세계 모든 사람이 24시간 내내 볼 수 있게 하려면 서버에 파일을 옮겨 둬야 된다.

● 클라이언트의 요청(Requsest)

○ 클라이언트인 내 컴퓨터에서 서버 있는 파일을 요청한다.

 

AIP 제공 ★ ★ ★ ★ ★ ★

- AIP 제공이란 메뉴판(API)에 따라 음식 (데이터)를 제공하는 것

● 메뉴판에 작성된 메뉴를 요청 (Request) 하면 셰프는 요리하여 완성된 음식(데이터)을 응답 (Response) 하는 역할을 한다.

● JavaScript에 fetch() 함수가 처리하려던 찜 목록 추가가 바로 이 요청임

★ ★ ★ ★ ★ 백앤드 개발자의 진짜 핵심 역할임

● 클라이언트의 요청 (Request)

○ 선택한 메뉴를 서버에게 요리(비즈니스 처리) 해달라고 요청한다.

 

● 서버의 응답 (Response)

○ 클라이언트의 요청을 해석함

 

챕터 2-2 : HTTP

학습 목표

● HTTP가 무엇인지 설명할 수 있다.

● HTTP 동작원칙, 주요특징, 구조,데이터 전송 방법을 설명할 수 있다.

 

 

● HyperText

○ 하이퍼링크 - a 태그를 통해 다른 웹 페이지나 정보로 즉시 이동할 수 있는 기능을 가진 '텍스트'를 말한다.

 

●Transfer Protocol

○ 텍스트로 작성된 정보를 전달하기 위한 규약을 말한다.

 

 

HTTP 동작 원칙

- HTTP 통신은 원칙을 따른다.

1. 클라이언트가 먼저 요청 한다.

2. 서버가 그 요청을 처리하고 응답 한다.

※ 절대로 서버가 먼저 클라이언트에게 말을 걸지 않는다.

- 점원이 가만히 있는 손님에게 마음대로 음식을 가져다주지 않는 것과 같다.

 

※ 클라이언트가 '요청'을 보내면 항상 '응답' 한다.

- 점원이 불렀는데 아무런 반응이 없거나, 시킨 음식이 아무리 기다려도 나오지 않는다면 문제가 있는 것과 같다.

 

HTTP 주요 특징

무상태성 ( Stateless )

● 서버는 클라이언트 이전 상태를 기억하지 않는다.

● 요리를 내준 손님을 1초 뒤에 완전히 잊어버리는(기억하지 않는) 것과 같다.

● 서버는 첫 주문에 응답할 때 번호표를 주고 다음 요청 때 번호표를 같이 보내주어야만 누구인지 식별할 수 있다.

 

비연결성 ( Connectionless )

● 클라이언트가 요청을 보내고 서버가 응답을 마치면 기본적으로 연결을 끊는다.

● 손님이 요리를 받고 나면 점원과 대화 (연결)가 일단 끝나는 것과 같다.

● 필요한 순가에만 연결하고 빠르게 끊음오러써 더 많은 요청을 효율적으로 처리할 수 있다.

 

 

HTTP 구조

- 모든 HTTP 구조는 3개의 파트로 구성되며 텍스트로 작성 된다.

1. 시작줄 ( Start - Line ) , 상태줄 ( Status - Line )

2. 헤더

3. 본문

 

※ 실제 HTTP 요청 (Request) 과 HTTP 응답 (Response) 텍스트를 살펴보기

 

HTTP 요청 (Request)

// (1) 시작 줄 (Start-Line)
Version: HTTP/1.1
Method: POST 
URL: 홈페이지 주소:80/items

// (2) 헤더 (Headers)
Content-Type: application/json
Accept: application/json, text/html
...

// (3) 본문 (Body)
{
  "name": "새우깡",
  "price": 1500,
  "category": "living"
}

 

(1) 시작 줄 ( Start - Line )

- 헤더와 본문을 해석하기 전 가장 먼저 전달되는 정보로, 우편을 보낼 때 박스 위에 적는 '보내는 사람/ 받는 사람/ 주소' 와 같다.

 

● Version

- 클라이언트가 요청을 보낼 때 어느 버전에 HTTP 요청을 보냈는지 알려줌

 

● Method

- 사용자가 주방에 음식을 주문할 때 다양한 방식으로 주문을 할수 있음

" 새로운 주문을 할게요" , "다른 메뉴로 주문을 바꿀게요 " , "주문을 취소 할게요."

- 클라이언트의 여러 방식에 요청(주문) 행동을 서버에 전달하기 위해 크게 4가지의 "동사"로 구분한다.

○ GET : 주문 조회 ( Read ) - 기존 찜 목록 데이터를 찾아주세요

 

○ POST : 주문 추가 ( Create ) - 데이터로 찜목록 새로 만들어주세요.

 

○ PUT/PATCH : 주문 수정 ( Update ) - 1번 찜 목록의 내용을 이것으로 바꿔 주세요

 

○ DELETE : 주문 취소 ( Delete ) : 1번 찜 목록을 삭제해 주세요.

 

● URL 

- "어디로" 주문을 넣을 건지 서버 IP 주소를 적은 것.

 

○ 홈페이지 주소 ( ip 주소)

○ : 80 (포트)

○ /items (경로)

fetch 함수에 시작 줄 (Start - Line ) 정보를 넣는다.

// const API_URL = "http://홈페이지 주소:80/items"
const response = await fetch(API_URL, {
    method: 'POST'
    // ...
});

fetch(API_URL...)의 API URL에 값인 " 홈페이지 주소: 80/items "을 URL로 입력한다.

method는 POST 입력해 준다.

 

(2) 헤더 ( Headers )

- 주문의 '상세 정보'를 의미하며, 사람의 머리와 같이 매우 중요한 요청 상세 정보를 전달할 수 있다.

 

Contnet - Type

- 본문(Body)에 담긴 콘텐츠 (데이터)가 어떤 형식인지 본문 해석 전에 알 수 있게 하는 정보

 

●  application/json (콘텐츠 형식)

○ 정보를 보고 서버는 아래 본문 'JSON'형식으로 작성 되어 있는지 알아채고 그에 맞게 해석

const response = await fetch(API_URL, {
    // ...
    Headers: { 'Content-Type': 'application/json' },
    // ...
});

 

ACCEPT

- 클라이언트 전달 받을 수 있는 콘텐츠를 서버에게 알려주기 위한 정보

● application/jison,text/html (컨텐츠 형식)

○ 클라이언트가 전달 받을 수 있는 콘텐츠 종류는 JSON, HTML이란 걸 알 수 있음.

 

(3) 본문 (Body)

Content-Type: application/json

- 현대 API 통신의 표준 데이터 형식으로 app.js가 '찜 목록 추가'를 서버에 요청할 때 사용자의 입력 값을 '객체' 형태로 주고 받기 위해 사용 됨

// JSON (JavaScriptObject Notation ) 자바스크립트 객체 표기법 약자
// key : value 쌍으로 이루어진 텍스트 형식

// 찜 목록 추가를 위해 사용자가 입력한 값을 -> Json 객체로 변환!
{
  "name": "새우깡", // 상품명 (key) : "새우깡" (value)
  "price": 1500,  // 가격 (key) : 1500 (value)
  "category": "living" // 카테고리(key) : 생활용품 (value)
}

특징 3가지
(1) 가벼움
(2) 사람이 읽기 쉬움
(3) JavaScript와 궁합이 완벽하다 ★★★★★★★★★★★★★★★★★★

// Json 객체 --> json 객체를 만들기
const newItem = {
  name: "새우깡",
  price: 1500,
  category: "living"
};

// --> body에 JSON을 텍스트로 변환하여 전달
const response = await fetch(API_URL, {
    // ...
    body: JSON.stringify(newItem)
});

 

Content-Type:text/html

- 본문에 HTML 파일을 텍스트 형태로 전달한다.

※ 서버가 클라이언트에게 HTML 파일을 응답 (Response)으로 전달할 때 사용한다.

// (1) 시작 줄 (Start-Line)
Method: GET 
URL: 홈페이지 주소:80/menu

// (2) 헤더 (Headers)
Content-Type: text/html
...

// (3) 본문 (Body)
<!DOCTYPE html>
<html>
  <head><title>네이버</title></head>
  ...
</html>

 

 

HTTP 응답 (Response)

● 서버(주방)가 클라이언트 (홀)에 돌려주는 '영수증과 완성된 요리' 입니다.

// (1) 상태 줄 (Status Line)
Version: HTTP/1.1
Status Code: 201 
Status Text: Created

// (2) 헤더 (Headers)
Content-Type: application/json

// (3) 본문 (Body)
{
  "id": "abc-123-xyz",
  "name": "새우깡",
  "price": 1500,
  "category": "living"
}

 

(1) 상태 줄 ( Status Line )

- 응답의 첫 번째 줄이며, "요청이 어떻게 처리 되었는지 " 그 최종 결과를 알려주는 '영수증'

 

Version 

- 클라이언트가 요청과 마찬가지로 응답을 전달할 때 어느 버전에 HTTP 응답을 보냈는지 알려준다.

※ 요청과 같은 버전에 응답을 보내야 한다.

 

Status code & Text

- 요청 처리 결과에 상태를 구분하는 코드로 서버에서 해당 상태 코드를 지정하여 보내줌

 

[app.js 코드 매칭]

"fetch 함수" 로 응답을 받은 직후, 가장 먼저 확인하는 것이 바로 " 상태 코드 "

// (app.js)
const response = await fetch(API_URL, ...);

// (A) 바로 이 부분! '상태 줄'의 '상태 코드'를 확인합니다.
if (!response.ok) { // .ok는 상태 코드가 200~299(성공)인지 확인
    throw new Error(`HTTP error! status: ${response.status}`); // 실패 시 에러
}

 

※ 백엔드 개발자는 이 "상태 코드"의 첫번째 자리만 봐도 무슨 일이 일어났는지 즉시 알수 있어야 한다 ★ ★ ★ ★

 

2xx ( 성공 ) 

200 

201 created



4xx (클라이언트 오류)

401 ( Unauthorized ) - 인증(로그인)오류

404 Not Found - 없는 메뉴



5xx (서버 오류)

500 Internal Server Error

 

(2) 헤더 (Headers)

- 응답에 대한 상세정보를 담은 운송장 

Content - Type

● 돌려주는 데이터도 JSON 형식

● JSON 형식으로 작성 되어 있는지 알아 채고 그에 맞게 해석 할 수 있음

 

(3) 본문 ( Body )

- 헤더와 함께 클라이언트에게 돌려줄 실제 데이터가 담기는 부분.

 

" newItem " 을 데이터베이스에 저장하면 id(고유 값) 생성 된다.
주문 성공의 증거로 "id"까지 포함된 완성된 객체 (JSON)을 "BODY"에 담아 보내준다.

// (app.js)
// (B) 바로 이 부분! '본문(Body)'의 'JSON 텍스트'를
//     JS가 쓸 수 있는 '객체'로 '해석(Parse)'합니다.
const addedItem = await response.json(); 

// (C) '해석'된 객체를 사용해 화면을 그립니다.
addItemToDOM(addedItem);

 

 

HTTP로 데이터를 전송 방법

- 요청에 경우에는 크게 두가지 방법으로 데이터를 서버로 전송할 수 있음

주소(URL)에 붙혀서 보내기 "GET"

본문 (Body)에 숨겨서 보내기 "(POST, PUT, PATCH)"

 

 

---

챕터 2-3 : REST API ( Application Programming Interface)

● Interface (인터페이스)

○ Inter (상호 간의) + face ( 마주 보다 )

○ 둘 이상이 마주 보고 통하는 접점

 

REST API 4가지 - CRUD

" 중복 되지 않도록 원칙을 사용 하는 방법 "
Method, URI 자체가 그것(API)의 목적을 명확히 나타낸다. 가능한 '그것만' 표현해야 된다.
새 API 사용법을 빠르게 익힐수 있음

Create   ------ POST ----------------- "생성" "추가" 

Read     ------ GET -----------------  "조회" (많은 정보가 필요 없음)

         ------ GET

Update   ------ PUT ------------------ " 정보 수정 " // 특정 항목을 전체적으로 수정

         ------ PATCH ---------------- " 상태 변경 " // 특정 값만 수정

Delete   ------ DELETE --------------- " 삭제 "

Mathod = POST, GET, PUT, PATCH, DELETE 

POST PUT PATCH ( 더 많은 내용을 담을 수 있음 ) - 큰 상자 
BODY라는 공간이 있어서 이곳에 큰 데이터를 실어 보낼수 있음

GET DELETE -작은 상자

★ add, modify, delete 그것으로 무엇을 하는가를 나타내는 "동사"는 URI에 가능한 포함되지 않는다.

요청을 처리 하는 상태 코드
Status code 200, 400, 500

 

POST 


PUT : 특정 항목을 전체 적으로 (갈아 치우는거) " 무거운 작업 " 
PATCH : 부분적으로 수정하는거 " 부분으로 하나씩 바꿀때 가벼운 작업 "

DELETE : 편지 봉투

 

 

 

지도 확대/축소 - 지도 라이브러리 API

● 라이브러리

 

REST API 설계 해보기

누가 API를 사용 하는가?

-> 블로그 방문자(조회) 블로그 관리자 (작성,수정,삭제)

 

설계 : 방문자 ->

관리자 ->

REST API 블로그 코드 설계

WHO,

HOW

PA