[항해99] WIL(Week I Learn) - 3주차

다사 다난 했던, 3주차가 끝났다.

저번주 금요일 부터 ~ 이번주 목요일 까지 이어진 Node.js 기초반 과정은

Node가 java보다 쉽다고 하던 사람들의 말을 듣고

아니면, 알고리즘 마라톤이 내심 할만하다고 생각했던 내 자신감을

박살내는 한 주차였다.

로그인 기능이 없는 블로그를 만드는 것이 과제였는데,

Restful API를 구성하는 것이 어떻게보면 핵심이라고 할 수 있었다.

강의를 들을 때는 쉽다고 생각했는데, 막상 직접 해보려니 내가 아는 것이

하나도 없다고 느꼈다. 정말로,

 

Restful APi라 함은 먼저  API(application programming interface)

애플리케이션 프로그래밍 인터페이스, 

그리고 Restful APi라면 API의 작동 방식에 대해서 조건과 일정한 형식으로 만들도록 요구한 것이라고

할 수 있다.

조건과 일정한 형식이라는게 딱딱한 표준 체계를 정해 놓고 만들라는 것이 아니라

리소스를 표현하고 데이터를 처리하는 과정을 구성된 API를 봄으로

충분히 어떤 과정을 진행하고 있고, 어떻게 동작하는지 보는 이로 하여금,

당연히 만든이도 포함해서 만들라는 것이다.

 

이런 Restful API의 제약 조건을 간단히 설명하면,

균일한 인터페이스

1. 요청은 리소스를 식별해야 합니다. 이를 위해 균일한 리소스 식별자를 사용합니다.
2. 클라이언트는 원하는 경우 리소스를 수정하거나 삭제하기에 충분한 정보를 리소스 표현에서 가지고 있습니다. 서버는 리소스를 자세히 설명하는 메타데이터를 전송하여 이 조건을 충족합니다.
3. 클라이언트는 표현을 추가로 처리하는 방법에 대한 정보를 수신합니다. 이를 위해 서버는 클라이언트가 리소스를 적절하게 사용할 수 있는 방법에 대한 메타데이터가 포함된 명확한 메시지를 전송합니다.
4. 클라이언트는 작업을 완료하는 데 필요한 다른 모든 관련 리소스에 대한 정보를 수신합니다. 이를 위해 서버는 클라이언트가 더 많은 리소스를 동적으로 검색할 수 있도록 표현에 하이퍼링크를 넣어 전송합니다.

무상태

REST 아키텍처에서 무상태는 서버가 이전의 모든 요청과 독립적으로 모든 클라이언트 요청을 완료하는 통신 방법을 나타냅니다. 클라이언트는 임의의 순서로 리소스를 요청할 수 있으며 모든 요청은 무상태이거나 다른 요청과 분리됩니다. 이 REST API 설계 제약 조건은 서버가 매번 요청을 완전히 이해해서 이행할 수 있음을 의미합니다. 

계층화 시스템

계층화된 시스템 아키텍처에서 클라이언트는 클라이언트와 서버 사이의 다른 승인된 중개자에게 연결할 수 있으며 여전히 서버로부터도 응답을 받습니다. 서버는 요청을 다른 서버로 전달할 수도 있습니다. 클라이언트 요청을 이행하기 위해 함께 작동하는 보안, 애플리케이션 및 비즈니스 로직과 같은 여러 계층으로 여러 서버에서 실행되도록 RESTful 웹 서비스를 설계할 수 있습니다. 이러한 계층은 클라이언트에 보이지 않는 상태로 유지됩니다.

캐시 가능성

RESTful 웹 서비스는 서버 응답 시간을 개선하기 위해 클라이언트 또는 중개자에 일부 응답을 저장하는 프로세스인 캐싱을 지원합니다. 예를 들어 모든 페이지에 공통 머리글 및 바닥글 이미지가 있는 웹 사이트를 방문한다고 가정해 보겠습니다. 새로운 웹 사이트 페이지를 방문할 때마다 서버는 동일한 이미지를 다시 전송해야 합니다. 이를 피하기 위해 클라이언트는 첫 번째 응답 후에 해당 이미지를 캐싱하거나 저장한 다음 캐시에서 직접 이미지를 사용합니다. RESTful 웹 서비스는 캐시 가능 또는 캐시 불가능으로 정의되는 API 응답을 사용하여 캐싱을 제어합니다.

온디맨드 코드

REST 아키텍처 스타일에서 서버는 소프트웨어 프로그래밍 코드를 클라이언트에 전송하여 클라이언트 기능을 일시적으로 확장하거나 사용자 지정할 수 있습니다. 예를 들어, 웹 사이트에서 등록 양식을 작성하면 브라우저는 잘못된 전화번호와 같은 실수를 즉시 강조 표시합니다. 서버에서 전송한 코드로 인해 이 작업을 수행할 수 있습니다.

라는 REST api의 몇 가지 원칙이 있다고 한다.

 

아무튼, 이런 api를 구성하기 위해서 다른 사람이 만든 것도 참고해보고

강의도 다시 보고 스스로도 생각하면서 만들어본 결과

과제 제출에 실패했다.

 

개인적인 사정으로 일요일과 월요일의 시간을 많이 비워야 했으나 이건 사실 핑계에 불과하다.

더 많은 시간과 노력을 들였다면 충분히 만들었을 것이다.

그리고 내가 만든 api는 충분히 Restful하지 못했다.

다른 사람의 코드를 참고하고, 강의에 나와있는 코드들을 참고하여 만들다보니

만든 나조차 이게 왜 이렇게 동작하는지 이해하지 못했다.

충분히 스스로에게 실망스러운 시간이었다.

제출하기 전날 밤 밤을 새면서 심장이 빨리뛰고 초조해지는 기분이 들었다.

위기감을 느낀 것이다.

4주차 때는 반드시 목표한 과제를 제출하는 것을 목표로 해야겠다.

 

---

package.json은 일종의 프로젝트의 정보를 정의하고 이에 의존하는 패키지 정보를 나타내는 파일이다.

npm init으로 생성하고, 패키지 버전관리를 하게 되는데 모듈화 시스템을 만들때 여러 패키지를 사용하게 된다.

이런 경우, package.json에 여러 패키지 정보를 기록하고, json파일을 통해

통합 개발환경을 구축할 수 있게 된다.

 

나또또한, package.json파일을 통해 express, mongoose를 설치하는 등의 행위로

쉽사리 여러 패키지를 관리할 수 있었다.

package.json파일이 없다면 에러가 나게 되는데,

npm can't find a package.json file in your current directory.

와 같은 에러가 나타날 수도 있다.

이제 로그인 기능과 회원가입 기능을 구현하여 전에 만든 블로그에

가져다 붙여야 하는데,

이번에는 해낼 수 있으리라 믿는다.