TIL
항해99 3주차 Til 5.23 ~ 5.29
- 이번 주차는 주특기 입문 주차이다.
총 주특기 주차가 3주로 입문,숙련,심화 과정이다.
이번에 과제는 블로그 서버 만들기 였다. 팀과제와 개인과제 둘로 나뉜다.
나는 Node.js 를 배우기 시작했다. 하지만 이번 주차에서 새로운 개념들이 많이 나왔다.
미들웨어, 라우팅, 프로미스, async, await, 동기,비동기... 더많은 개념들이 존재했다.
이것들을 이해하기 까지 많은 구글링과 이해하게 되는 걸리는 시간이 오래 걸렸다.
그래도 어느정도 개념을 이해하고 나니 코드 보는게 한결 쉬어지긴 했다.
3주차 Node.js 입문
개인과제
팀과제
- 팀과제는 용어 개념정리 였다.
- 팀원 4명이서 10개의 키워드를 가지고 그것에 대한 정리와 설명이 부가적으로 설명되었다.
- 다들 이해하기 쉽게 예를 적절히 들어가며 알려줘서 혼자 공부할때 보다 쉽게 이해할수 있었다.
Node 입문주차 배운것들
-
서버가 만들어지는 기능을 알수 있었다
-
CRUD를 통해 RESFULL 한 api 개발을 할 수 있게 되었다.
-
서버를 이해할 수 있는 눈이 생긴 것 같다. 아직까진 흐름을 이해하는데 신경을 집중하고 있다.
-
새로운 개념들을 혼자 이해하려면 오래 걸려야 할 것 들이 스터디를 통해 보다 쉽게 개념을 잡을 수가 있었다.
3주차 후기
-
계속 나오는 문제이긴 하지만 강의 영상이 너무 부족한 부분들이 많은 것 같다.
-
개념정리하는 것도 알아서 해야하는 것 같고 비전공자 배려가 너무 없는 것 같습니다.
-
혼자 정리하고 과제 만들면서 3주전의 나와 지금의 나는 아는 정도가 많이 달라진게 보입니다.
-
아직 입문이고 아직 갈길이 멀다는 것 또한 느끼게 된 주차 인것 같습니다.
4주차
-
3주차는 주특기node.js 배우는 주차였다면 4주차는 좀더 심화된 내용을 배운다
-
과제가 3주차에 있던 것을 회원가입, 로그인 api 기능을 추가하는 형태였다.
-
감이 잡히는 것 같지만 아직 부족한 점이 많은 것 같다.
* 이제막 시작한 코린이의 한주,한주....
Restful API
RESTful 이란
- HTTP와 URI 기반으로 자원에 접근할 수 있도록 제공하는 애플리케이션 개발 인터페이스이다. 기본적으로 개발자는 HTTP 메소드와 URI 만으로 인터넷에 자료를 CRUD 할 수 있다.
- 'REST API'를 제공하는 웹 서비스를 'RESTful' 하다고 할 수 있다.
- RESTful은 REST를 REST 답게 쓰기 위한 방법으로, 누군가가 공식적으로 발표한 것은 아니다.
RESTful API 개발 원칙
a. 자원을 식별할 수 있어야 한다.
- URL (Uniform Resource Locator) 만으로 내가 어떤 자원을 제어하려고 하는지 알 수 있어야 한다. 자원을 제어하기 위해서, 자원의 위치는 물론 자원의 종류까지 알 수 있어야 한다는 의미이다.
- Server가 제공하는 정보는 JSON 이나 XML 형태로 HTTP body에 포함되어 전송 시킨다.
b. 행위는 명시적이어야 한다.
- REST는 아키텍쳐 혹은 방법론과 비슷하다. 따라서 이런 방식을 사용해야 한다고 강제적이지 않다. 기존의 웹 서비스 처럼, GET을 이용해서 UPDATE와 DELETE를 해도 된다.
- 다만 REST 아키텍쳐에는 부합하지 않으므로 REST를 따른다고 할 수는 없다.
c. 자기 서술적이어야 한다.
- 데이터에 대한 메타정보만 가지고도 어떤 종류의 데이터인지, 데이터를 위해서 어떤 어플리케이션을 실행 해야 하는지를 알 수 있어야 한다.
- 즉, 데이터 처리를 위한 정보를 얻기 위해서, 데이터 원본을 읽어야 한다면 자기 서술적이지 못하다
d. HATEOS (Hypermedia as the Engine of Application State)
- 클라이언트 요청에 대해 응답을 할 때, 추가적인 정보를 제공하는 링크를 포함할 수 있어야 한다.
- REST는 독립적으로 컴포넌트들을 손쉽게 연결하기 위한 목적으로도 사용된다. 따라서 서로 다른 컴포넌트들을 유연하게 연결하기 위해선, 느슨한 연결을 만들어줄 것이 필요하다.
- 이때 사용되는 것이 바로 링크이다. 서버는 클라이언트 응용 애플리케이션에 하이퍼 링크를 제공한다.
- 클라이언트는 이 하이퍼 링크를 통해서 전체 네트워크와 연결되며 HATEOAS는 서버가 독립적으로 진화할 수 있도록 서버와 서버, 서버와 클라이언트를 분리 할 수 있게 한다.
REST의 단점들
- REST는 point-to-point 통신모델을 기본으로 한다. 따라서 서버와 클라이언트가 연결을 맺고 상호작용해야하는 어플리케이션의 개발에는 적당하지 않다.
- REST는 URI, HTTP 이용한 아키텍처링 방법에 대한 내용만을 담고 있다. 보안과 통신규약 정책 같은 것은 전혀다루지 않는다. 따라서 개발자는 통신과 정책에 대한 설계와 구현을 도맡아서 진행해야 한다.
- HTTP에 상당히 의존적이다. REST는 설계 원리이기 때문에 HTTP와는 상관없이 다른 프로토콜에서도 구현할 수 있기는 하지만 자연스러운 개발이 힘들다. 다만 REST를 사용하는 이유가 대부분의 서비스가 웹으로 통합되는 상황이기에 큰 단점이 아니게 되었다.
- CRUD 4가지 메소드만 제공한다. 대부분의 일들을 처리할 수 있지만, 4가지 메소드 만으로 처리하기엔 모호한 표현이 있다.
package.json
npm이라는 오픈소스 패키지 생태계를 사용하기 위한 명세이자, 프로젝트의 의존성 관리를 위한 명세, 또 이 생태계로의 배포를 위한 명세라고 볼 수 있다.
프로젝트의 개발만을 위한 목적인지, 패키지를 배포하기 위한 목적인지에 따라 용도가 갈릴 수 있겠다라고 생각했다.
일반적으로 패키지를 불러와서 프로젝트를 개발하는게 목적이라면, 의존성 관리에 대한 명세가 더 중요할 것이다.
