TIL 12 (Redux, sort(), HTTP, 멱등성)(2021.10.18)

Recent Posts

Today

Total

관리 메뉴

상권's

TIL 12 (Redux, sort(), HTTP, 멱등성)(2021.10.18) 본문

~2022 작성 글/TIL

TIL 12 (Redux, sort(), HTTP, 멱등성)(2021.10.18)

라마치 2021. 10. 18. 21:11

Redux data flow 사진 출처 O.REILLY

STORE = 애플리케이션의 STATE들이 모여있는 곳.

ACTIONS = 객체의 형태로 이루어져 있으면서, STATE의 변화에 대해서 설명.

REDUCERS = STATE가 어떻게 바뀌는 지에 대해서 설명.

다양한 REDUCERS들은 combineReducers를 통해서 관리를 할 수 있음.

=> 스토어를 통해서 변경된 STATE를 리액트 컴포넌트로 보내준다.

리덕스가 없을 때에는, STATE를 변경하기 위해서 STATE가 선언되어 있는 곳으로 이동한 후, 변경하고, 또 해당 컴포넌트로 이동을 해야되는데... STORE를 통해서 보관을 하고 관리를 할 수 있다.

아직 기본적인 틀에 대해서만 학습을 해서 내용이 너무 간략하지만, 추후 더 많은 학습을 통해서 내용을 보충하고, 정확하게 기재하도록 하겠습니다.

React Component에는 Class Component, Functional Component들이 있습니다.

Class Component는 코드가 더 길어지고, 복잡하고, 느리긴 하지만 다양한 기능들을 제공 할 수 있었습니다.

반면, Functional Component의 경우에는 코드는 간결하고, 빠르지만 제공하는 기능이 Class Component 보다 적었습니다.

이러함에도 Class Component를 이용했던 이유는, state의 관리와 라이프 사이클 메소드의 사용 때문이었습니다.

이후, React 16.8 Hook이 개발이 되면서 Functional Component에서도 state를 관리할 수 있는 useState, 렌더링 이후에 작업할 수 있는 useEffect 기능들이 추가 되었습니다.

const arr = [5, 6, 1, 4, 8, 9, 0, 2, 100, 101, 999, 10000]
// 숫자가 담긴 배열에 대해서 sort()

let sortedArr = arr.sort( (a, b) => a - b)
// sort로 배열의 요소들을 오름차순으로 정리할 때,
console.log(sortedArr)
// [0, 1, 2, 4, 5, 6, 8, 9, 100, 101, 999, 10000]

let sortedArr = arr.sort( (a, b) => b - a)
// sort로 내림차순으로 정리할 때,
console.log(sortedArr)
// [10000, 999, 101, 100, 9, 8, 6, 5, 4, 2, 1, 0]

let sortedArr = arr2.sort()
// 그냥 sort()를 하게 뒤면 제일 첫번째 숫자로 오름차순을 정리한다
console.log(sortedArr)
// [0, 1, 100, 10000, 101, 2, 4, 5, 6, 8, 9, 999]

Array.prototype.sort() 출처 MDN

sort() 메서드는 배열의 요소를 적절한 위치에 정렬한 후 그 배열을 반환합니다. 정렬은 stable sort가 아닐 수 있습니다. 기본 정렬 순서는 문자열의 유니코드 코드 포인트를 따릅니다.

정렬 속도와 복잡도는 각 구현방식에 따라 다를 수 있습니다.

구문

arr.sort([compareFunction])

매개변수

compareFunction Optiona 정렬 순서를 정의하는 함수. 생략하면 배열은 각 요소의 문자열 변환에 따라 각 문자의 유니 코드 코드 포인트 값에 따라 정렬됩니다.

반환 값

정렬한 배열. 원 배열이 정렬되는 것에 유의하세요. 복사본이 만들어지는 것이 아닙니다.

설명

compareFunction이 제공되지 않으면 요소를 문자열로 변환하고 유니 코드 코드 포인트 순서로 문자열을 비교하여 정렬됩니다. 예를 들어 "바나나"는 "체리"앞에옵니다. 숫자 정렬에서는 9가 80보다 앞에 오지만 숫자는 문자열로 변환되기 때문에 "80"은 유니 코드 순서에서 "9"앞에옵니다.

compareFunction이 제공되면 배열 요소는 compare 함수의 반환 값에 따라 정렬됩니다. a와 b가 비교되는 두 요소라면,

compareFunction(a, b)이 0보다 작은 경우 a를 b보다 낮은 색인으로 정렬합니다. 즉, a가 먼저옵니다.
compareFunction(a, b)이 0을 반환하면 a와 b를 서로에 대해 변경하지 않고 모든 다른 요소에 대해 정렬합니다. 참고 : ECMAscript 표준은 이러한 동작을 보장하지 않으므로 모든 브라우저(예 : Mozilla 버전은 적어도 2003 년 이후 버전 임)가 이를 존중하지는 않습니다.
compareFunction(a, b)이 0보다 큰 경우, b를 a보다 낮은 인덱스로 소트합니다.
compareFunction(a, b)은 요소 a와 b의 특정 쌍이 두 개의 인수로 주어질 때 항상 동일한 값을 반환해야합니다. 일치하지 않는 결과가 반환되면 정렬 순서는 정의되지 않습니다.

sort( (a, b) => a - b ) => 오름차순으로 정렬
위의 코드를 다음과 같이 구현할 수 있다.
function compare(a, b) {
  if (a < b) {
  // 0보다 작은 경우 a를 b보다 낮은 색인으로 정렬합니다. 즉, a가 먼저옵니다.
    return -1;
  }
  if (a > b) {
  // 0보다 큰 경우, b를 a보다 낮은 인덱스로 소트합니다.
    return 1;
  }
  // a === b 
  // 0을 반환하면 a와 b를 서로에 대해 변경하지 않고 모든 다른 요소에 대해 정렬
  return 0;
}
// 요소 a와 b의 특정 쌍이 두 개의 인수로 주어질 때 항상 동일한 값을 반환


sort( (a, b) => b - a ) => 내림차순으로 정렬(반대)

활용

사람의 이름과 나이 정보를 가진 person 객체가 있고, 나이순으로 정렬한다.

const persons = [
  { name: 'John', age: 30 },
  { name: 'Ana', age: 20 },
  { name: 'Chris', age: 25 }, // trailing comma ES2017
];

function comparePerson(a, b) {
  if (a.age < b.age) {
    return -1;
  }
  if (a.age > b.age) {
    return 1;
  }
  return 0;
}

console.log('persons.sort(comparePerson)', persons.sort(comparePerson));
// [{name: 'Ana', age: 20}, {name: 'Chris', age: 25}, {name: 'John', age: 30}]

persons.sort( (a, b) => a.age - b.age)
// 이렇게 간편하게 작성해도 동일한 결과를 볼 수 있다

활용2

let names = ['Ana', 'ana', 'john', 'John'];
console.log('names.sort()', names.sort());
// ['Ana', 'John', 'ana', 'john']
// 대문자 J가 a 보다 앞으로 오는 이유는 아스키값이 소문자가 더 크기 떄문

names = ['Ana', 'ana', 'john', 'John'];
console.log('names.sort(compareFunction)', names.sort((a, b) => {
  if (a.toLowerCase() < b.toLowerCase()) {
    return -1;
  }
  if (a.toLowerCase() > b.toLowerCase()) {
    return 1;
  }
  return 0;
}));
// ['Ana', 'ana', 'john', 'John']
// sort의 compareFunction 에서 toLowerCase나, toUpperCase를 진행할 수 있다.

=> 오늘 코플릿을 풀면서, sort()에 대해 제대로 학습하지 않아서 실수를 했던 부분입니다. 다음부터는 이런 실수를 하지 않도록 주의하겠습니다.

코플릿 문제

-2021.10.18 오늘의 코플릿-
정수를 요소로 갖는 배열을 입력받아 3개의 요소를 곱해 나올 수 있는 최대값을 리턴해야 합니다.

입력으로 주어진 배열은 중첩되지 않은 1차원 배열입니다.
배열의 요소는 음수와 0을 포함하는 정수입니다.
배열의 길이는 3 이상입니다.

    // 정수를 요소로 갖는 배열을 입력받아 3개의 요소를 곱해 나올 수 있는 최대값을 리턴해야 합니다.
  
    // 음수가 하나일 경우에는 음수는 제외한다.
    // 음수가 둘 이상일 경우, 음수가 큰 숫자에 해당하면 음수 2개를 포함시킨다.
    // sort 를 써서 정렬을 한다.
    // findindex를 써서 0을 찾는다. => 0이 없다면 뒤에서 세개를 곱한다.
    // 0 이 있다면,멘 뒤에꺼랑 맨 앞에꺼랑 곱하고, 앞에서 두번째랑, 세번째를 곱해본 후, 큰 수를 리턴한다.

첫 수도코드 => 오늘 코플릿을 풀면서 했던 실수는 크게 2가지로, 첫째는, 문제를 읽고 첫 수도코드를 작성하면서, 음수가 들어갈 수도 있기 때문에 꼭 0 있을 거다! 라는 이상한 발상으로 이러한 수도코드를 작성하게 되었습니다..

둘째, sort()에 대해서 숙지는 하고 있었지만, 단순히 sort()쓰게 되면 한 자리 이상의 수도 제일 첫 숫자를 기준으로 오름차순 정리가 되는 지에 대해서 몰랐습니다..

그래도 다행스럽게, 문제를 해결하기 위한 방법인

// 0 이 있다면,멘 뒤에꺼랑 맨 앞에꺼랑 곱하고, 앞에서 두번째랑, 세번째를 곱해본 후, 큰 수를 리턴한다.

이 부분은 직접 생각을 해내서 다행이라고는 생각하지만.. 이상한 착각과 제대로 학습하지 않아 문제를 푸는데 큰 어려움이 있었습니다.

최종 수도 코드.

// sort((a, b) => a - b ) 로 배열 정렬 후 변수에 할당한다.
// A 음수가 있을 경우에는 앞에서 두개를 곱해야 한다. => - * -는 양수가 된다.
// B 양수만 있을 경우에는 뒤에서 세개를 곱하면 된다.

// A랑 B를 비교해서 큰 숫자를 리턴한다.

클라이언트-서버 콘셉트를 이해할 수 있다.

클라이언트-서버 아키텍처를 이해할 수 있다.

리소스가 존재하는 곳(서버)과, 리소스를 사용하는 앱(클라이언트)을 분리시킨 것을 2티어 아키텍처 또는, 클라이언트-서버 아키텍처라고 부릅니다.

클라이언트-서버 아키텍처에서는 요청이 선행되고 응답이 옵니다.

일반적으로 데이터베이스를 통해서 리소스(정보)를 저장을 하고, 서버가 리소스를 전달해주는데, 이러한 형태를 3티어 아키텍처라고 합니다.(클라이언트 - 서버 - 데이터베이스)

클라이언트는 보통 플랫폼에 따라 구분됩니다.

브라우저를 통해 주로 이용하는 웹(Web) 플랫폼에서의 클라이언트는 웹사이트 또는 웹 앱이라고 부릅니다. iOS나 안드로이드와 같은 스마트폰/태블릿 플랫폼, 그리고 윈도우와 같은 데스크탑 플랫폼에서 이용하는 앱 역시 클라이언트가 될 수 있습니다.

서버의 종류

1. 파일 서버 => 파일을 제공하는 앱.

2. 웹 서버=> 웹사이트에서 필요로 하는 정보를 제공하는 앱.

3. 메일 서버=> 메일을 주고 받을 수 있도록 도와주는 앱.

HTTP를 이용한 클라이언트-서버 통신을 이해할 수 있다.

프로토콜은 통신 규약입니다. HTTP(HyperText Transfer Protocol)를 이용해 주고받는 메시지는 "HTTP 메시지"라고 부릅니다.

API의 개념을 이해할 수 있다.

서버는 클라이언트에게 리소스를 잘 활용할 수 있도록 인터페이스(interface)를 제공해줘야 합니다. 이것을 API라고 합니다.

API(Application Programming Interface 응용 프로그램 프로그래밍 인터페이스)는 응용 프로그램에서 사용할 수 있도록, 운영 체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스를 뜻한다.
주로 파일 제어, 창 제어, 화상 처리, 문자 제어 등을 위한 인터페이스를 제공한다.

서버가 API를 구축해놓아야 클라이언트가 이를 활용할 수 있습니다. 보통 인터넷에 있는 데이터를 요청할 때에는 HTTP라는 프로토콜을 사용하며, 주소(URL, URI)를 통해 접근할 수 있게 됩니다.

HTTP 요청 메소드

GET = 조회

POST = 추가

PUT(또는 PATCH) = 갱신

PUT은 리소스의 모든 것을 업데이트 한다. => 입력되지 않은 값이 있다면 null값으로 변한다.

PATCH는 리소스 중에서 요청된 건에 대해서만 업데이트 한다. => 입력되지 않은 값은 변경 전과 동일.

DELETE = 삭제

브라우저의 작동 원리를 이해할 수 있다.

브라우저의 주소창에 입력한 URL은 서버가 제공되는 환경에 존재하는 파일의 위치를 나타냅니다.

URL과 URI의 차이를 이해할 수 있다.

URL은 Uniform Resource Locator의 줄임말로, 네트워크 상에서 웹 페이지, 이미지, 동영상 등의 파일이 위치한 정보를 나타냅니다.

URL 요소

scheme = 통신 방식(프로토콜)을 결정, 일반적인 웹 브라우저에서는 http(s)를 사용

hosts = 웹 서버의 이름이나 도메인, IP를 사용하며 주소

url-path = 웹 서버에서 지정한 루트 디렉토리부터 시작하여 웹 페이지, 이미지, 동영상 등이 위치한 경로와 파일명

URI는 Uniform Resource Identifier의 줄임말로, 일반적으로 URL의 기본 요소인 scheme, hosts, url-path에 더해 query, bookmark를 포함합니다.

query = 웹 서버에 보내는 추가적인 질문 => 키 벨류 값으로, URL-path에 덧붙여서 클라이언트가 어떤 특정 리소스에 접근하길 원하는 지에 대한 정보가 추가적으로 담긴다.

URI는 URL을 포함하는 상위개념입니다. 따라서, 'URL은 URI다.' 는 참이고, 'URI는 URL이다.' 는 거짓입니다.

부분명칭설명

file://, http://, https://	scheme	통신 프로토콜
127.0.0.1, www.google.com	hosts	웹 페이지, 이미지, 동영상 등의 파일이 위치한 웹 서버, 도메인 또는 IP
:80, :443, :3000	port	웹 서버에 접속하기 위한 통로
/search, /Users/username/Desktop	url-path	웹 서버의 루트 디렉토리로부터 웹 페이지, 이미지, 동영상 등의 파일이 위치까지의 경로
q=JavaScript	query	웹 서버에 전달하는 추가 질문

IP 주소와 PORT에 대해 이해할 수 있다.

IP address(Internet Protocol address, IP 주소)란,

네트워크에 연결된 특정 PC의 주소를 나타내는 체계

IPv4는 .(닷)으로 구분되어서, 각 덩어리마다 0부터 255까지 나타낼 수 있습니다. 이 시스템을 따르면, 2^(32)인 약 43억 개의 IP 주소를 표현할 수 있습니다.

그 중에서 몇 가지는 이미 용도가 정해져 있습니다. 특히 다음과 같은 IP 주소는 반드시 기억해야 합니다.

localhost, 127.0.0.1 : 현재 사용 중인 로컬 PC를 지칭합니다.
0.0.0.0, 255.255.255.255 : broadcast address, 로컬 네트워크에 접속된 모든 장치와 소통하는 주소입니다. 서버에서 접근 가능 IP 주소를 broadcast address 로 지정하면, 모든 기기에서 서버에 접근할 수 있습니다.

PC의 사용량이 많아지면서, IPv6(IP version 6) 나타나게 됩니다. IPv6는 표기법을 달리 책정하여 2^(128)개의 IP 주소를 표현할 수 있습니다.

터미널에서 리액트를 실행하면 나타나는 화면에는, 로컬 PC의 IP 주소인 localhost 뒤에 :3000과 같은 숫자가 표현됩니다. 이 숫자는 IP 주소가 가리키는 PC에 접속할 수 있는 통로(포트)을 의미합니다.

포트 번호는 0~ 65,535 까지 사용할 수 있습니다. 그 중에서 0 ~ 1024번 까지의 포트 번호는 주요 통신을 위한 규약에 따라 이미 정해져 있습니다. 그중에서 반드시 알아야 할 잘 알려진 포트 번호는 다음과 같습니다.

22 : SSH
80 : HTTP
443: HTTPS
더 많은 포트 번호 확인하기

DNS와 IP 주소의 관계를 설명할 수 있다.

Domain name

웹 브라우저를 통해 특정 사이트에 진입을 할 때, IP 주소를 대신하여 사용하는 주소. 도메인 이름을 이용하면, 한눈에 파악하기 힘든 IP 주소를 보다 분명하게 나타낼 수 있습니다.

DNS

DNS는 Domain Name System의 줄임말로, 호스트의 도메인 이름을 IP 주소로 변환하거나 반대의 경우를 수행할 수 있도록 개발된 데이터베이스 시스템

도메인 주소는 오른쪽부터 왼쪽으로 최상위 도메인과 여러개의 도메인으로 구성되어 있습니다.

탑 레벨 도메인 = .com, .kr, .net 등 도메인의 가장 오른쪽에 위치하는 도메인.

kr, us와 같은 국가코드를 사용하는 도메인은 co, ac와 같은 2단계 도메인과 함께 사용.

서브도메인 = `www, m`와 같은 제일 왼쪽에 위치한 도메인들.

호스트 이름으로 불리기도 하는 서브도메인은 웹 사이트의 특정 부분을 나눠서 보여줘야 하는 경우 사용

도메인 서버(존)은 도메인을 관리하며, 모든 도메인을 관리하는 루트 네임 서버, TLD를 관리하는 네임 서버, 권한 있는 네임 서버로 구성.

안정성을 위해 최소한 두개 이상의 서버가 하나의 도메인 네임을 담당. => 서버가 과부하나 서비스 거부 공격을 당할 경우를 대비.

루트 도메인 네임 서버는 각 최상위 도메인 네임 서버들의 주소를 알고 있으며 최상위 도메인 네임 서버는 권한 있는 네임 서버의 주소를 알고 있습니다.

권한 있는 네임 서버는 `example.com`등의 도메인 IP 주소 및 도메인 정보를 관리하는 권한을 가진 서버.

‘DNS Lookup’ URL에 주소를 입력할 경우 다음과 같이 작동

1. 브라우저는 리졸버에게 IP주소를 요청. 

여기서 리졸버는 요청받은 도메인의 IP 주소를 찾기위해 여러 네임 서버에 반복적인 질의를 하는 이름 서버입니다.

 리졸버는 우선 기존에 찾아본 도메인정보 내용이 담긴 캐시 파일을 살펴봅니다.    해당되는 도메인정보가 있다면 즉시 IP주소를 리턴합니다.  

해당되는 도메인 정보를 찾을수 없는 경우 2번을 진행합니다. 

2. DNS 리졸버는 IP주소를 얻기 위해 네임 서버들에게 재귀적인 쿼리를 진행.

 루트, 탑레벨, 권한있는 도메인 서버에 차례대로 쿼리를 진행하며 IP주소를 알아냅니다.   이때 리졸버는 쿼리수를 줄일 목적으로 기록되지 않은 도메인 네임 서버들의 주소를 저장하기도 합니다.  

(ISP: 인터넷 서비스 제공자)

3. 마지막으로 리졸버는 전달받은 IP주소를 기록하고 브라우저에게 전달합니다. 

도메인 네임 서버는 응답을 보내기위해 한개 이상의 존 파일이라는 파일을 가지고 있습니다. 존 파일은 네임과 클래스, TTL, 레코드 타입, 레코드 데이터로 구성된 레코드들로 구성되어 있습니다. 네임 서버들은 이러한 존 파일들을 바탕으로 요청에 해당되는 레코드를 리턴합니다. 리졸버는 이 레코드를 살펴보고 리턴해야할 IP 혹은 다음에 쿼리를 진행할 서버의 주소를 확인합니다.

레코드의 상세 정보는 다음과 같습니다. 이름은 `example.com`과 같은 도메인 네임 혹은 서브 도메인의 이름 등을 저장합니다. 레코드 클래스는 네트워크 타입을 지정합니다. 일반적으로 IN(인터넷)으로 지정됩니다. TTL은 Time To Live의 약자로서 리졸버가 레코드를 몇 초동안 저장할 지를 명시합니다.  해당 시간이 지나면 리졸버는 해당 레코드를 삭제합니다. 레코드 타입은 레코드 데이터의 내용의 형식입니다.

대표적인 레코드 타입은 다음과 같습니다. A - 데이터가 IPv4 주소임을 명시합니다. IPv4 주소는 보통 알고있는 127.0.0.1과 같은 주소를 말합니다. AAAA - 데이터가 IPv6 주소임을 명시합니다. IPv6주소는 IPv4주소가 부족해지자 새롭게 도입된 주소 형식입니다.

CNAME - 데이터가 도메인 주소임을 명시합니다.
NS - 데이터가 도메인 네임 서버들의 주소임을 명시합니다.
SOA - 데이터가 도메인 네임 서버들중 주 서버의 정보들에 대한 데이터입니다. 주 네임 서버와 통신할 수 있는 포트번호, TTL, 도메인 주소등이 적혀 있습니다.

보이는 곳의 통신을 이해할 수 있다.

AJAX의 개념을 이해할 수 있다.

AJAX 란? Asynchronous JavaScript And XMLHttpRequest의 약자로,

JavaScript, DOM, Fetch, XMLHttpReqest, HTML 등의 다양한 기술을 사용하는 웹 개발 기법입니다.

AJAX의 가장 큰 특징은 웹 페이지에 필요한 부분에 필요한 데이터만 비동기적으로 받아와 화면에 그려낼 수 있다는 것입니다.

2. AJAX의 두가지 핵심 기술

AJAX를 구성하는 핵심 기술은 JavaScript와 DOM, 그리고 Fetch입니다.

전통적인 웹 어플리케이션에서는 <form> 태그를 이용해 서버에 데이터를 전송 => 서버는 요청에 대한 응답으로 새로운 웹 페이지를 제공 => 클라이언트에서 요청을 보내면 매번 새로운 페이지로 이동해야 했습니다.

Fetch를 이용해서 서버로 부터 페이지를 이동하지 않고 필요한 데이터를 받음 => Fetch는 사용자가 현재 페이지에서 작업을 하는 동안 서버와 통신할 수 있도록 함. => Fetch가 응답을 받을 때까지, 페이지가 멈추는 것이 아니라 비동기적으로 다른 부분은 이용 가능 => 필요한 부분만 DOM에 적용시켜 해당 부분만 변경

XHR과 Fetch

Fetch는 이전에 사용하던 XHR(XMLHttpRequest)의 단점을 보완한 새로운 Web API이며, XML보다 가볍고 JavaScript와 호환되는 JSON을 사용함.

3. AJAX의 장점

- 서버에서 HTML을 완성하여 보내주지 않아도 웹페이지를 만들 수 있습니다.

AJAX를 사용하면 서버에서 완성된 HTML을 보내주지 않아도 필요한 데이터를 비동기적으로 가져와 브라우저에서 화면의 일부만 업데이트 하여 렌더링 할 수 있습니다.

- 표준화된 방법 이전에는 브라우저마다 다른 방식으로 AJAX를 사용했으나, XHR이 표준화 되면서부터 브라우저에 상관 없이 AJAX를 사용할 수 있게 되었습니다.

- 유저 중심 어플리케이션 개발 AJAX를 사용하면 필요한 일부분만 렌더링하기 때문에 빠르고 더 많은 상호작용이 가능한 어플리케이션을 만들 수 있습니다.

- 더 작은 대역폭(네트워크 통신 한 번에 보낼 수 있는 데이터의 크기) 필요한 데이터를 텍스트 형태(JSON, XML 등) 보내면 되기 때문에 비교적 데이터의 크기가 작습니다.

4. AJAX의 단점

Search Engine Optimization(SEO)에 불리

검색 사이트에서는 전세계 사이트를 돌아다니며 각 사이트의 모든 정보를 긁어와, 사용자에게 검색 결과로 보여줍니다. 그런데 AJAX 방식의 웹 어플리케이션의 HTML 파일은 뼈대만 있고 데이터는 없기 때문에 사이트의 정보를 긁어가기 어렵습니다.(서버에서 비동기적으로 필요한 데이터를 가져옴)

뒤로가기 버튼 문제

AJAX에서는 이전 상태를 기억하지 않기 때문에 뒤로가기 등의 기능을 구현하기 위해서는 별도로 History API를 사용해야 합니다.

SSR과 CSR의 차이를 이해할 수 있다.

SSR(Server Side Rendering) 서버에서 웹 페이지를 렌더링

브라우저가 서버 URI에 GET 요청 => 서버가 웹 페이지 렌더링 한 후 브라우저에 전송

사용자가 다른 경로로 이동할 경우에, 서버는 이 작업을 반복.

(데이터베이스의 데이터가 필요한 경우, 서버는 데이터베이스의 데이터를 불러온 다음 웹 페이지를 완전히 렌더링 된 페이지로 변환한 후에 브라우저에 응답)

CSR(Client Side Rendering) 클라이언트(웹 브라우저)에서 페이지 렌더링

브라우저가 서버에 요청 => 서버는 웹 페이지를 렌더링하는 대신, 웹 페이지의 골격이 될 단일 페이지와 JavaScript를 클라이언트 전송 => 클라이언트가 웹 페이지를 받으면, 웹 페이지와 함께 전달된 JavaScript 파일은 브라우저에서 웹 페이지를 완전히 렌더링 된 페이지로 변경.

브라우저가 다른 경로로 이동하면 브라우저는 브라우저가 요청한 경로에 따라 페이지를 다시 렌더링. 이때 보이는 웹 페이지의 파일은 맨 처음 서버로부터 전달받은 웹 페이지 파일과 동일한 파일

(데이터베이스의 데이터가 필요할 경우, 웹 페이지를 렌더링하는 데에 필요한 데이터를 API 요청으로 해소합니다.)

The Difference

렌더링 = SSR은 서버에서 페이지를 렌더링하고, CSR은 브라우저(클라이언트)에서 페이지를 렌더링.

브라우저는 사용자가 다른 경로를 요청할 때마다 페이지를 새로고침 하지 않고, 동적으로 라우팅을 관리합니다.

Use SSR

SEO(Search Engine Optimization) 가 우선순위인 경우, 일반적으로 SSR(Server Side Rendering) 을 사용.
웹 페이지의 첫 화면 렌더링이 빠르게 필요한 경우에도, 단일 파일의 용량이 작은 SSR 이 적합.
웹 페이지가 사용자와 상호작용이 적은 경우, SSR 을 활용.

Use CSR

SEO 가 우선순위가 아닌 경우, CSR을 이용 가능.
사이트에 풍부한 상호 작용이 있는 경우, CSR 은 빠른 라우팅으로 강력한 사용자 경험을 제공.
웹 애플리케이션을 제작하는 경우, CSR을 이용해 더 나은 사용자 경험(빠른 동적 렌더링 등)을 제공.

CORS의 개념을 이해할 수 있다.

출처 MDN

어떤 요청이 CORS를 사용하나요?

교차 출처 공유 표준은 다음과 같은 경우에 사이트간 HTTP 요청을 허용합니다.

위에서 논의한 바와 같이, XMLHttpRequest와 Fetch API 호출.
웹 폰트(CSS 내 @font-face에서 교차 도메인 폰트 사용 시), so that servers can deploy TrueType fonts that can only be cross-site loaded and used by web sites that are permitted to do so.
WebGL 텍스쳐.
drawImage() (en-US)를 사용해 캔버스에 그린 이미지/비디오 프레임.
이미지로부터 추출하는 CSS Shapes.

단순 요청(Simple requests)

일부요청은 CORS preflight 를 트리거하지 않습니다. Fetch 명세(CORS를 정의한)는 이 용어를 사용하지 않지만, 이 기사에서는 "simple requests"라고 하겠습니다. "simple requests"는 다음 조건을 모두 충족하는 요청입니다:

다음 중 하나의 메서드
- GET
- HEAD
- POST
유저 에이전트가 자동으로 설정 한 헤더 (예를들어, Connection, User-Agent (en-US), Fetch 명세에서 “forbidden header name”으로 정의한 헤더)외에, 수동으로 설정할 수 있는 헤더는 오직 Fetch 명세에서 “CORS-safelisted request-header”로 정의한 헤더 뿐입니다.
- Accept
- Accept-Language
- Content-Language
- Content-Type (아래의 추가 요구 사항에 유의하세요.)
Content-Type 헤더는 다음의 값들만 허용됩니다.
- application/x-www-form-urlencoded
- multipart/form-data
- text/plain
요청에 사용된 XMLHttpRequestUpload 객체에는 이벤트 리스너가 등록되어 있지 않습니다. 이들은 XMLHttpRequest.upload 프로퍼티를 사용하여 접근합니다..
요청에 ReadableStream 객체가 사용되지 않습니다.

"preflighted" request는 위에서 논의한 “simple requests” 와는 달리, 먼저 OPTIONS 메서드를 통해 다른 도메인의 리소스로 HTTP 요청을 보내 실제 요청이 전송하기에 안전한지 확인합니다. Cross-site 요청은 유저 데이터에 영향을 줄 수 있기 때문에 이와같이 미리 전송(preflighted)합니다.

(실제 POST 요청에는 Access-Control-Request-* 헤더가 포함되지 않습니다. OPTIONS 요청에만 필요합니다.)

=> 이론은 어느정도 이해했지만, 추가적인 학습을 통해서 정확하게 사용하는 방법에 대해서 숙지하도록 하겠습니다.

HTTP messages의 구조를 설명할 수 있다.

HTTP의 동작 방식을 이해할 수 있다.

HTTP는 HyperText Transfer Protocol의 줄임말로, HTML과 같은 문서를 전송하기 위한 응용 계층 프로토콜

HTTP는 웹 브라우저와 웹 서버의 소통을 위해 디자인

전통적인 클라이언트-서버 모델에서 클라이언트가 HTTP messages 양식에 맞춰 요청을 보내면, 서버도 HTTP messages 양식에 맞춰 응답합니다. HTTP는 특정 상태를 유지하지 않는 특징이 있습니다.

HTTP의 특징: Stateless(무상태성)

Stateless
Stateless는 말 그대로 상태를 가지지 않는다는 뜻입니다. HTTP로 클라이언트와 서버가 통신을 주고 받는 과정에서, HTTP가 클라이언트나 서버의 상태를 확인하지 않습니다. 사용자는 쇼핑몰에 로그인하거나 상품을 클릭해서 상세 화면으로 이동하고, 상품을 카트에 담거나 로그아웃을 할 수도 있습니다. 클라이언트에서 발생한 이런 모든 상태를 HTTP 통신이 추적하지 않습니다. 만약 쇼핑몰에서 카트에 담기 버튼을 눌렀을 때, 카트에 담긴 상품 정보(상태)를 저장해둬야 합니다. 그러나 HTTP는 통신 규약일 뿐이므로, 상태를 저장하지 않습니다. 따라서, 필요에 따라 다른 방법(쿠키-세션, API 등)을 통해 상태를 확인할 수 있습니다.

HTTP messages

HTTP messages 는 클라이언트와 서버 사이에서 데이터가 교환되는 방식입니다. HTTP messages에는 다음과 같은 두 가지 유형이 있습니다.

요청(Requests)
응답(Responses)

요청(Requests)과 응답(Responses)은 다음과 같은 유사한 구조를 가집니다.

start line : start line에는 요청이나 응답의 상태를 나타냅니다. 응답에서는 status line이라고 부릅니다.
HTTP headers : 요청을 지정하거나, 메시지에 포함된 본문을 설명하는 헤더의 집합입니다.
empty line : 헤더와 본문을 구분하는 빈 줄이 있습니다.
body : 요청과 관련된 데이터나 응답과 관련된 데이터 또는 문서를 포함합니다.

이 중 start line과 HTTP headers를 묶어 요청이나 응답의 헤드(head)라고 하고, payload(전송되는 데이터)는 body라고 이야기합니다.

HTTP requests와 responses를 구분할 수 있다.

요청(Requests)

Start line [HTTP Verb + URI + HTTP version Number]

수행할 작업(GET, PUT, POST 등)이나 방식(HEAD or OPTIONS)을 설명하는 HTTP method
요청 대상(일반적으로 URL이나 URI) 또는 프로토콜, 포트, 도메인의 절대 경로는 요청 문액에 작성됩니다.
요청 형식
1. origin 형식 : ?와 쿼리 문자열이 붙는 절대 경로입니다. POST, GET, HEAD, OPTIONS 등의 method와 함께 사용합니다.

POST / HTTP 1.1
GET /background.png HTTP/1.1
HEAD /test.html?query=alibaba HTTP/1.1
OPTIONS /anypage.html HTTP/1.0

2. absolute 형식 : 완전한 URL 형식으로, 프록시에 연결하는 경우 대부분 GET method와 함께 사용합니다.

GET http://developer.mozilla.org/en-US/docs/Web/HTTP/Messages HTTP/1.1

3. authority 형식 : 도메인 이름과 포트 번호로 이루어진 URL의 authority component 입니다. HTTP 터널을 구축하는 경우, CONNECT와 함께 사용할 수 있습니다.

CONNECT developer.mozilla.org:80 HTTP/1.1

4. asterisk 형식 : OPTIONS 와 함께 별표(*) 하나로 서버 전체를 표현합니다.

OPTIONS * HTTP/1.1

HTTP 버전에 따라 HTTP message의 구조가 달라집니다.

Headers

헤더 이름(대소문자 구분이 없는 문자열), 콜론( : ), 값을 입력합니다.

General headers : 메시지 전체에 적용되는 헤더로, body를 통해 전송되는 데이터와는 관련이 없는 헤더입니다.
Request headers : fetch를 통해 가져올 리소스나 클라이언트 자체에 대한 자세한 정보를 포함하는 헤더를 의미합니다. User-Agent, Accept-Type, Accept-Language과 같은 헤더는 요청을 보다 구체화합니다. Referer처럼 컨텍스트를 제공하거나 If-None과 같이 조건에 따라 제약을 추가할 수 있습니다.
Representation headers : 이전에는 Entity headers로 불렀으며, body에 담긴 리소스의 정보(컨텐츠 길이, MIME 타입 등)를 포함하는 헤더입니다.

Body

모든 요청에 body가 필요하지는 않습니다. POST나 PUT과 같은 일부 요청은 데이터를 업데이트하기 위해 사용합니다.

Single-resource bodies(단일-리소스 본문) : 헤더 두 개(Content-Type과 Content-Length)로 정의된 단일 파일로 구성됩니다.
Multiple-resource bodies(다중-리소스 본문) : 여러 파트로 구성된 본문에서는 각 파트마다 다른 정보를 지닙니다. 보통 HTML form과 관련이 있습니다.

응답(Responses)

Status line [HTTP version Number + status code + Reason Pharse]

현재 프로토콜의 버전(HTTP/1.1)
상태 코드 - 요청의 결과를 나타냅니다. (200, 302, 404 등)
상태 텍스트 - 상태 코드에 대한 설명

Headers

대소문자 구분 없는 문자열과 콜론(:), 값을 입력합니다.

General headers : 메시지 전체에 적용되는 헤더로, body를 통해 전송되는 데이터와는 관련이 없는 헤더입니다.
Response headers : 위치 또는 서버 자체에 대한 정보(이름, 버전 등)와 같이 응답에 대한 부가적인 정보를 갖는 헤더로, Vary, Accept-Ranges와 같이 상태 줄에 넣기에는 공간이 부족했던 추가 정보를 제공합니다.
Representation headers : 이전에는 Entity headers로 불렀으며, body에 담긴 리소스의 정보(컨텐츠 길이, MIME 타입 등)를 포함하는 헤더입니다.

Body

201, 204와 같은 상태 코드를 가지는 응답에는 본문이 필요하지 않습니다. 응답의 body는 다음과 같이 두 종류로 나눌 수 있습니다.

Single-resource bodies(단일-리소스 본문) :
- 길이가 알려진 단일-리소스 본문은 두 개의 헤더(Content-Type, Content-Length)로 정의합니다.
- 길이를 모르는 단일 파일로 구성된 단일-리소스 본문은 Transfer-Encoding이 chunked 로 설정되어 있으며, 파일은 chunk로 나뉘어 인코딩되어 있습니다.
Multiple-resource bodies(다중-리소스 본문) : 서로 다른 정보를 담고 있는 body입니다.

출처 MDN

- 201 Created

=> 요청이 성공적이었으며 그 결과로 새로운 리소스가 생성되었습니다. 이 응답은 일반적으로 POST 요청 또는 일부 PUT 요청 이후에 따라옵니다.

- 204

=> No Content요청에 대해서 보내줄 수 있는 콘텐츠가 없지만, 헤더는 의미있을 수 있습니다. 사용자-에이전트는 리소스가 캐시된 헤더를 새로운 것으로 업데이트 할 수 있습니다.

이미지 출처

출처 MDN

멱등성

동일한 요청을 한 번 보내는 것과 여러 번 연속으로 보내는 것이 같은 효과를 지니고, 서버의 상태도 동일하게 남을 때, 해당 HTTP 메서드가 멱등성을 가졌다고 말합니다. 다른 말로는, 멱등성 메서드에는 통계 기록 등을 제외하면 어떠한 부수 효과(side effect)도 존재해서는 안됩니다. 올바르게 구현한 경우 GET, HEAD, PUT, DELETE 메서드는 멱등성을 가지며, POST 메서드는 그렇지 않습니다. 모든 안전한 메서드는 멱등성도 가집니다.

멱등성을 따질 땐 실제 서버의 백엔드 상태만 보면 되며, 각 요청에서 반환하는 응답 코드는 다를 수 있습니다. 첫 번째 DELETE 요청이 200을 반환한다면, 그 이후는 아마 404를 반환할 것입니다. DELETE가 멱등성을 가진다는 것은, REST API에서 개발자는 DELETE 메서드를 사용해 "목록의 마지막 항목 제거" 기능을 구현해서는 안된다는 것입니다.

다만, 서버는 멱등성을 보장하지 않으며, 일부 애플리케이션은 잘못된 구현으로 멱등성 제약을 어길 수도 있습니다.

GET /pageX HTTP/1.1는 멱등성을 가집니다. 여러 번 연속해서 호출해도 클라이언트가 받는 응답은 동일합니다.

POST /add_row HTTP/1.1는 멱등성을 갖지 않습니다. 여러 번 호출할 경우, 여러 열을 추가합니다.

DELETE /idX/delete HTTP/1.1의 상태 코드는 응답마다 달라질 수 있지만, 그럼에도 멱등성을 가집니다.

추가적으로 학습할 링크1

추가적으로 학습할 링크2

저작자표시 비영리 변경금지

'~2022 작성 글 > TIL' 카테고리의 다른 글

TIL 14 (2021.10.20) (0)	2021.10.20
TIL 13 (2021.10.19) (0)	2021.10.19
TIL 11 (2021.10.17) (0)	2021.10.17
TIL 10 코드 리뷰 (2021.10.08) (0)	2021.10.16
TIL 9 (2021.10.15) (0)	2021.10.15

'~2022 작성 글/TIL' Related Articles

Comments

상권's

TIL 12 (Redux, sort(), HTTP, 멱등성)(2021.10.18) 본문

TIL 12 (Redux, sort(), HTTP, 멱등성)(2021.10.18)

'~2022 작성 글 > TIL' 카테고리의 다른 글

티스토리툴바