더그는 피아노를 좋아해

Javascript의 Import, Export의 간단한 사용 예시를 메모합니다.

- export.js -

export const dog = {
	name: '멍멍',
	color: 'white',
};

export const cat = {
	name: '야옹',
	color: 'silver',
};

const bear = {
	name: '푸우',
	color: 'brown',
};

export default bear;
// export를 한 곳에서 할 경우, export{dog, cat}의 형태로 가능

- import.js -

import bear, { dog, cat } from './export.js';
// bear 경우, default export이기 때문에 import 시 원하는대로 작명 가능
// import * as objects from './import.js'로 한 번에 다 import도 가능
// import 문법을 사용 할 경우, package.json 파일에 "type": "module" 추가 할 것

HTTP Cookies와 Web Storage의 정의와 특징에 관해 정리합니다.

본 게시글은 하기의 순서로 진행됩니다.

1. HTTP의 Stateless적 특징

2. Cookies의 정의 및 특징

3. Web Storage의 정의 및 특징

• HTTP의 Stateless적 특징

HTTP는 stateless적 특징을 가집니다.

하지만 sessionless하진 않습니다.

그렇다면 stateless한 통신, stateful한 통신 각각의 장점은 어떤 것이 있을까요?

각각을 세 개씩만 추려보면 하기와 같습니다.

하기 2페이지를 참고 하였습니다.

https://www.mygreatlearning.com/blog/stateful-vs-stateless/

https://www.section.io/engineering-education/stateful-vs-stateless-architectures/

- Stateless한 통신의 장점 -

1. Scalability의 용의성
2. Client의 request의 고립을 통한 서버측 부담 경감
3. 간결한 구조

- Stateful한 통신의 장점 -

1. 통신상태 monitoring의 가능
2. Client의 통신 track을 통한 end-user의 사용편의성 향상
3. Server의존성 증대로 인한 보안 강화

기본적으로 stateless한 HTTP 이지만,

사용자의 사용편의성 향상과 같은 이유로 stateful한 특징도 취할 수 있으면 좋겠습니다.

이를 위해 필요한 것이 HTTP Cookies입니다.

• Cookies의 정의 및 특징

HTTP Cookies의 정의는 하기와 같습니다.

이렇듯, HTTP Cookies는 stateless한 HTTP의 특성을 보완하기 위해 사용됩니다.

또, HTTP Cookies의 중요 특징은 2가지가 있습니다.

1. Client측에 저장되고 임의로 수정이 가능한 점

2. 특정 Path(하위 포함)로 Request를 호출 시, 매번 서버로 전송된다는 점

입니다.

첫 번째의 특징으로 인해 상대적으로 보안에 취약해집니다.

이러한 이유로 Cookies에 개인정보와 같은 정보를 담아서는 안됩니다.

두 번째의 특징으로 인해 Client와 Server 양측의 불필요한 traffic이 발생됩니다.

이러한 단점을 보완하기 위해 Web Storage사용이 권장됩니다.

• Web Storage의 정의 및 특징

HTTP Cookies의 정의는 하기와 같습니다.

Web Storage의 특징은 하기와 같습니다.

Web Storage의 특징 중,

Data가 server로 전송되지 않는다는 점이 Cookies와의 중요한 차이인 것 같습니다.

소스코드를 작성할 때,

여러 곳에 사용 된 변수를 손으로 하나하나 고치느라 오류가 발생하는 경우가 있습니다.

작업 시 시간도 많이 들게되고,

오류가 발생 할 여지도 커져 좋지 않습니다.

이러한 때 사용하기 좋은 VS Code 내장기능이 있습니다.

F2키로 실행 가능한 Rename Symbol 기능입니다.

사용법은 간단합니다.

1. 동시에 수정되어야 할 변수 중 하나를 클릭합니다. (드래그 필요 없음)

2. F2키를 누르거나, 우클릭 후 'Rename Symbol'을 클릭합니다.

3. 작은 창이 하나 뜹니다.

4. 변수명을 수정합니다.

그림으로 보면 하기와 같습니다.

HTTP messages의 정의 및 구성에 관한 내용을 요약정리합니다.

• HTTP Messages의 정의

MDN에 기재 된 HTTP Messages의 정의는 하기와 같습니다.

HTTP messages are how data is exchanged between a server and a client. 

There are two types of messages: requests sent by the client to trigger an action on the server, and responses, the answer from the server.

• HTTP Messages의 구조 

HTTP Messages는 Requests, Responses 각각 start-line, headers, body의 정보로 이루어져 있습니다.

• Requests

start-line

Requests start-line은 HTTP method, request target, HTTP version 세 가지 정보로 이루어져 있습니다.

HTTP method는 GET, POST, PUT, DELETE등이 있습니다.

request target은 대체로 URL인 경우가 많습니다.

HTTP version은 messages의 구조를 정의하여 response로 받고싶은 version을 지시합니다.

headers 

Requests headers는 resource fetch에 필요한 정보, client자체에 대한 추가정보로 이루어져 있습니다.

body

Requests body는 HTTP method가 POST, PUT등과 같이 server 데이터 수정에 필요한 정보를 보낼 때 사용됩니다.

GET, DELETE 등과 같은 method의 경우 HTTP messages에 포함되지 않습니다.

• Responses

start-line

Responses start-line은 HTTP version, status code, status text로 이루어져 있습니다.

headers

Responses header는 Age, Location, Server 정보 등의 추가정보로 이루어져 있습니다.

body

Responses body는 대체로 Single-resource body, Multiple-resource body로 나뉩니다.

Single-resource body는 Content-Type, Content-Length로 정의되는 단일 정보입니다.

Multiple-resource body는 대체로 HTML Forms등과 관련 되어있습니다.

모든 Responses가 body를 가지는 것은 아닙니다.

status code 201, 204과 같이 그 자체로 처리결과가 충분히 묘사되는 경우는 대체로 Reponses body를 갖지 않습니다.