1. 문제의 발단

• API를 이제 직접 작성해 보는 단계가 되었다.
• Postman을 이용해 간단하게 작업이 가능하다.

2. JSON

• Javascript 형식으로 네트워크를 통해 정보를 전달하고 받을 때 이용하는 파일의 형식이다.
  • 이때 문자열에서 이를 네이티브 객체로 바꾸는 것을 '파싱(Parsing)' 한다고 한다.
• 일반적인 JSON은 '객체' 형태로 생겼다.

[
  {
    "id": 1,
    "username": "Hendrix",
    "text": "Hello World",
    "from": "Korea",
    "date": "2021-07-30T03:54:21.134"
  },
  // 다른 객체들이 더 있을 수 있다.
]

3. REST API

• API들 중에서도 오늘날 널리 사용되는 한 API의 형태.
• 과거에는 SOAP을 사용했지만 너무 복잡해서 REST로 바뀌었다.
• 그래서 데이터에 대한 상태는 GET, POST, PUT, DELETE 등등으로 표현되어 사용하게 되는 것이다.

4. Postman을 이용한 테스트

• Postman : HTTP API 테스트를 위한 도구이다.
• 어떻게 사용하는가?
  1. URL을 GET으로 요청하기.  ex) http://1.11.11.11:3000/data/messages
  2. 그러면 응답으로 JSON형식이 온다.
  3. POST로 GET을 바꾸고 Body에 파일 형식을 JSON으로 바꾸고 아래에 JSON형식으로 새로운 객체를 만들고 Send 하면 추가할 수 도 있다.
  4. 오른쪽 아래 HTTP 상태도 뜬다!

1. 클라이언트, 서버, API, http

• 클라이언트 : 우리가 직접적으로 보고 있는 곳. 서버에 데이터를 '요청'한다.
• 서버 : 데이터를 전달해 주는 역할. 클라이언트에게 요청을 받아서 '응답'한다.
• API : 프로그램들이 서로 소통하는 방식. api에는 다양한 종류가 있고, 그것을 이용해 클라이언트도 서버와 소통하게 되는 것이다.
• HTTP : 이때, 프로그램들이 소통할 때 지켜줘야 할 약속이다. ex) 상황근무 서면서 전화받을 때 '통신보안!'을 일단 박고 본다.
  • 이때 이 약속들의 종류 중 하나가 HTTP이고, HTTPS, FTP, SMTP 등등 다양한 종류들이 있다.
  • HTTP API의 디자인을 우리가 직접 해 줄 수 있으며, 그것을 위해 사용하는 주요 메서드들이 있다.
    • GET : 조회(Read)
    • POST : 추가(Create)
    • PUT 혹은, PATCH : 갱신(Update)
    • DELETE : 삭제(Delete)
  • HTTP는 무상 태성으로 작동한다. 즉, 상태를 저장하지 않는다. 만약 저장하고 싶으면 쿠키 등을 통해 하게 된다.
  • 응답이 오면 HTTP 응답 상태 코드를 보여준다. 이것이 위의 고양이 그림이 된다. 주로 우리가 볼 수 있는 코드는 위의 4장의 고양이들이 알려줄 것이다.
    • 200 : OK. 완료됐다. 다행이다.
    • 403 : 서버에 요청은 했으나 권한이 없어 거절당했다. 고양이는 모레에서 볼일을 보는 것이 옳다.
    • 404 : 서버가 요청받은 리소스를 찾을 수 가 없다. 고양이는 자기가 안 보이면 아무도 못 찾는 줄 안다. 귀엽다.
    • 500 : 서버가 뭔가 예상하지 못 한 상황이다. 저 다급한 손가락을 보라.

2. HTTP messages

•  클라이먼트와 서버는 HTTP messages의 양식에 맞게 알아서 소통하게 된다.
• HTTP messages는 이렇게 생겼다. 요청할때와 응답할 때 거의 같은 구조이다.
  • start line : 첫번째 줄이다. 요청하는 상태를 보여준다. 응답 시에는 status line이라고 한다. 주소창에서 보면 '?' 뒤에 문자열 즉, 경로가 붙는다.
  • HTTP headers : 요청을 지정하거나 본문 내용의 설명이 적혀있다.
  • empty line : 그냥 빈 줄이다. 구분선으로 생각하면 된다.
  • body : 내용이다. 요청과 응답에 따라 알아서 사용한다.

3. AJAX

• Asynchronous Javascript And XML을 줄여 놓은 것이다.
• 과거에 사용하던 방식은 서버에 배포되어 있던 HTML 문서를 클라이언트가 받아와서 사용했다. 그래서 무언가 바뀔 때마다, 다시 모든 HTML 문서를 다시 받아와야 했다. 그러한 끊김은 사용자로 하여금 좋은 경험이 될 리가 없다. (the very frist web page를 생각해 보자)
• 그래서, 이제 서버에서 필요한 데이터만 가져오기로 했다.  이 기술을 'XMLHttpRequest'라고 하며(fetch라고도 할 수 있다), 작동 방식은 JSON과 같은 포맷으로 필요한 데이터를 자바스크립트를 이용해, 동적으로 HTML 문서로 바꿔 사용하게 되었다.
• 이것이 공식적으로 'AJAX'라는 이름으로 사용하게 된 것이다!
• 이것은 SPA(Single Page Application)의 기초가 되었다는 것이다!

4. IP 주소

• IP주소 : 컴퓨터가 가지고 있는 주소이다. 주소라고 부르는 이유도 진짜 '주소'이기 때문이다.
• 훈련병 때 자주 썼던 편지를 생각해 보자. 군대에 가기 전에 훈련소 주소와 교번이 나오면 우리의 주소를 정확이 페이스북, 인스타에 공지하고, 받을 사람 주소도 정확하게 적어서 일단 입대한다. 그래야 편지를 주고받을 수 있다.
• 이처럼 나의 ip주소, 통신할 대상의 ip주소를 알아야 통신을 하게 되는 것이다.

5. IP주소는 어디서 오나요?

• 우리가 네트워크에 접속될 때, 그때 AP(Access Point)가 컴퓨터에게 IP주소를 할당해 준다.
• 그러므로, 연결된 네트워크가 많으면? IP주소도 많아진다. 물론, 정상적인 상황에는 네트워크를 두 개씩 연결할 일이 없다.
• 하지만 항상 정해저 있는 IP주소도 있다.
  • 127.0.0.1 : 지금 사용 중인 로컬 PC
  • 0.0.0.0 혹은, 255.255.255.255 : 지금 로컬 네트워크에 접속된 모든 장치와 소통할 수 있는 주소

6. PORT

• 통신하고 싶은 컴퓨터의 IP주소로 찾아가면, 포트 번호를 통해 그 찾아온 주소의 컴퓨터에 돌아가고 있는 서비스에 접근할 수 있도록 할당해 준다.
• 이미 사용 중인 포트는 중복으로 사용할 수 없다. 서비스 종류에 따라 포트를 나눠줘야 하기 때문이다.
• 통신 규약에 따라 정해진 포트 번호들이 있고 우리가 주로 사용하는 포트 번호만 따로 알고 있으면 된다.
  • 22 : SSH
  • 80 : HTTP
  • 443 : HTTPS
  • 3000 : 임시 포트

7. URL & URI

URL

• Uniform Resource Locator을 줄여놓은 것이다.
• 이는 네트워크에서 저장된 이미지나, 동영상 등이 존재하는 파일의 경로의 위치를 말한다.
• scheme://host [port][/path]의 형태로 만들어져 있다.
  • scheme : 프로토콜을 적어 주면 된다. (http, https 같은 거)
  • host [:port] : ip주소를 호스트에 적게 될 것이다. 하지만 DNS 서버가 자동으로 도메인으로 ip주소를 바꿔준다. 그래서 우리는 ip주소를 따로 입력하지 않고, naver.com 같은 것만 적어도 알아서 접속이 되는 것이다. 마찬가지로, port번호도 알아서 생략해서 생각한다. 물론, 적어줘도 똑같이 접속된다.
  • [/path] : 파일의 경로가 된다.  ex) /dataninfo/hero/detail.php처럼 적혀있다. 이때, 'dataninfo폴더 안에, hero폴더 안에, detail.php라는 파일이 있을 것이다'라는 추측이 가능하다.

URI

• Uniform Resource Identifier을 줄여놓은 것이다.
• 서버가 주는 환경에서 파일을 나타내는 주소가 된다.
• 우리가 보고 있는 그 위에 그 주소가 맞다.
• URL보다 조금 더 나아간 형태이다. 추가적으로 전달해 주는 데이터가 더 적혀 있다.
• scheme://host [port][/path][? query]의 형태로 만들어져 있다.
  • [? query] : 내가 전달하는 데이터. 대부분 숫자 같은 형태로 되어 있다. 사용자로부터 어떠한 정보를 전달받아 앞에서 보았던 포트를 통해 전달되어 우리는 서비스를 사용할 수 있다.

8. CSR & SSR

CSR(Client Side Rendering)

• 클라이언트가 모든 일을 맡아서 한다.
• 어떠한 주소에 접속할 때, 서버에서 HTML 파일을 받아오게 된다.
• 이때, 이 HTML 파일은 내용은 텅 비어 있고, 애플리케이션의 구동에 필요한 자바스크립트 링크만 연결된 상태로 오게 된다.
• 덕분에 처음에 접속하면 텅 빈 화면만 나온다.
• 이후에 서버에서 자바스크립트에 필요한 프레임워크와 소스코드를 포함한 자바스크립트 파일을 주게 된다.
• 또 그 이후에 추가로 필요한 데이터까지 받아 오면 이것들을 사용해 유저에게 최종적으로 애플리케이션을 보여주게 된다.
  • 단점 1 : 첫 화면 로딩이 길다. 받아와야 할 데이터가 꽤 되기 때문
  • 단점 2 : 검색에 문제가 생긴다. HTML 파일을 읽어서 검색에 노출시키는데 정작 HTML 파일은 비어있기 때문이다.

SSR(Server Side Rendering)

• 서버에서 필요한 데이터를 가져와 HTML 파일을 만들어서 동적인 동작이 가능한 소스코드와 함께 클라이언트에게 보내준다.
• 클라이언트는 바로 쓰면 된다!
  • 장점 1 : CSR과는 다르게 로딩은 당연히 빠르다. 그저 받아서 쓰면 되기 때문이다.
  • 장점 2 : CSR보다 검색 효율도 좋다. HTML 파일에 내용이 있기 때문이다!
  • 단점 1 : 전체 웹사이트를 받아 와야 하기 때문에 역시 끊김이 있다.
  • 단점 2 : 서버가 힘들어한다. 서버가 하는 일이 많기 때문이다.
  • 단점 3 : 만약, 용량이 큰 자바스크립트 파일을 아직 다운로드하지 못한 경우, 페이지를 볼 수는 있으나, 반응이 없는 상황이 생길 수 있다.

그냥 보면 헷갈릴 수 있다. 하지만 우리에게는 예시가 있다. 바로 지금 당신의 주소창을 보라!
광명을 찾을 수 있을 것이다.
그 주소창을 보면서 천천히 포스팅을 읽으면 될 것 같다!
위의 고양이 사진이 더 가지고 싶다면 아래의 링크로 가면 된다.

https://http.cat/

1. 왜 씁니까?

• promise를 조금 더 깔끔하고 더 동기적으로 보이게끔 만든다.
• 콜백 함수나 promise가 너무 많으면 코드를 읽기 너무 힘들다. 그저 promise에 요소를 조금 더 해서 사용하는 'syntactic sugar'이 된다!

2. 어떻게 사용하나요?

//! promise Ver.
function findUser() {
	return new Promise((resolve, reject) => {
		// 뭔가 통신을 한다던지 지연이 일어난다.
        resolve('Hendrix');
	});
}

const user = findUser();
user.then(console.log);
console.log(user)

//! async Ver.
async function findUser() {
		// 뭔가 통신을 한다던지 지연이 일어난다.
        return 'Hendrix';
}

const user = findUser();
user.then(console.log);
console.log(user)

• 물론 둘의 결과는 똑같다. 그저 promise를 줄여서 async로 퉁 친 것이다. 하지만 가끔은 promise가 필요할 때가 있다. 마치 for... 과 while처럼 말이다.

function delay(el) {
	return new Promise(resolve => setTimeout(resolve, el));
}

async function beatIt() {
	await delay(1000);
    return 'Oh No...Help';
}

async function defense() {
	await delay(2000);
    return 'Miss!';
}

• await은 setTimeout에 의해 소괄호에 적힌 시간에 맞게 기다렸다가 리턴하게 된다.
• 이외에 promise.all이나  then으로 연결할 수 있는 부분은 다른 포스팅에서 정리하는 것이 좋을 것 같다.

1. Promise를 왜 쓰는가?

• 비동기 함수들을 사용할 때 콜백 함수를 너무 많이 사용하면 복잡해서 읽기가 매우 힘들다.
• 그래서 자바스크립트 내장 메서드 'promise'를 쓴다.

2. Producer

const proise = new Promise((resolve, reject) => {
	console.log('Doing Someting');
    setTimeout(() => {
		resolve('name')
    	reject(new Error('No Name'))
    }, 2000);
});

• Promise는 class다. 그래서 일단 new를 사용해 만들게 된다.
• resolve는 기능이 정상적으로 돌아가 마지막에 리턴할 함수 => 위의 예시에서 보이듯이 알맞은 인자를 전달해 준다.
• reject는 기능이 돌아가다가 뭔가 오류가 생겼을 때 리턴할 함수

3. Consumers

• 위에서 만들어 놓은 promise를 이용하는 방법이 된다.

promise
	.then((value) => {
		console.log(value); // name
	})
    .catch(error => {
		console.log(error)
    })
    .finally(() => {
		console.log('End')
	});

• 위의 예시에서 then은 기능이 올바르게 작동한다면 나오게 될 기능을 하게 된다. 이때, value는 우리가 promise에서 resolve라는 콜백 함수로 전달한 값인 'name'이 전달되게 된다.
• 만약 문제가 생긴다면? reject로 준 Error가 발생한다.
• 문제가 발생해서  reject 콜백 함수가 사용되면, then이 promise를 다시 불러오게 되고, 그 불러온  promise에 catch를 다시 등록시키게 된다. 그러면 에러가 발생했을 때, 그것을 다시 잡아와 catch안에서 사용하게 된다. 이를 '체이닝'이라고 한다.
• finally는 가장 마지막에 에러가 발생하든, 올바르게 실행되든 상관없이 실행된다.

4. fs.readFile()

• 비동기적으로 파일을 읽어 온다는 의미이다.

fs.readFile('읽어올 파일의 경로', 'utf8(옵션, 대부분 utf8)', (err, data) => {
	if(err) {
		throw err; // 문제가 있다면 err를 던진다!
	}
	console.log(data); // 문제가 없다면 콘솔에 data를 입력한다.
})

• 파일의 불러올 방식으로는 주로, 'utf8'이 사용된다. 사람이 읽을 수 있는 언어로 만들어주는 느낌이다.
• 콜백 함수에서 err가 발생하지 않으면 자동으로 null이 되며, data에 내용이 전달된다.