NODE.JS의 시간이 드디어 찾아왔다..
요즘 많이 보고 익히고 알게 되어 기쁘긴한데 하루하루가 벌써 지루해지고 있다.
같은 날이 반복되는 것 같은 기분?
그 여파로 오늘 0530 월요일인데 WIL을 쓰려고 기억을 더듬어 저번주와 저저번주가 겹쳐보여 기억을 떠올리는데 다소의 시간이지만 시간이 걸렸다는 사실에 깜짝 놀랬다.
하지만 모르고 시작한게 아니니
그냥 그렇구나 하고 앞으로 3개월 안되는 기간.
후. 숨 다잡고 그냥 해보자.
0520~2526
NODE.JS의 개념은 물론 API 명세서를 작성하는 것 부터 시작해서 여러가지 해 나갈 것이 많다.
그도 그럴게 NODE.JS만 처음인게 아니라 백앤드 작성을 할 때 뭐부터 할지 전혀 모르고 있었으니
시작점이 저~~ 멀리 있었던게 어쩔 수 없는 사실이다.
새로운 개념이 머리에 들어오고 그걸 머리에서 인식할 때까지 시간이 많이 걸린다.
중간중간 산책과 짧은 낮잠, 커피를 통해 하루를 조금씩 끊어 쓰는게 좋을 것 같다.
발표 자료를 만드는 건 쉬운데, 하아;
저번주에 고민했던 운동은 하는게 좋은 것 같고 시간 활용은 유연한게 좋은 것 같다.
하루종일 컴퓨터를 부둥켜안고 지내봤자 개념을 배울 때는 시간이 절대적으로 필요하지만, 그 이후에 대해서는 여러가지를 고려할 수 있는 맑은 정신으로 구글링을 하며 창조적(?)조립을 해야하기에
중간중간의 작은 휴식도 중요한 것 같다.
RESTFUL API
api와 rest api의 기본적 개념
API 또는 애플리케이션 프로그래밍 인터페이스
는 애플리케이션이나 디바이스가 서로 간에 연결하여 통신할 수 있는 방법을 정의하는 규칙 세트입니다.
REST API는 REST(REpresentational State Transfer)(상태 전송의 대표적 형태의) 아키텍처 스타일의 디자인 원칙을 준수하는 API입니다. 이러한 이유 때문에 REST API를 종종 RESTful API라고도 합니다.
컴퓨터 과학자인 Roy Fielding 박사가 2000년에 자신의 박사학위 논문에서 처음으로 정의한 REST는 개발자에게 비교적 높은 수준의 유연성과 자유를 제공합니다.
SOAP 또는 XML-RPC 등의 일부 API는 개발자에 대한 엄격한 프레임워크를 부과합니다. 그러나 REST API는 거의 모든 프로그래밍 언어를 사용하여 개발이 가능하며, 다양한 데이터 포맷을 지원할 수 있습니다. 유일한 요구사항은 이들이 아키텍처 제한사항으로도 알려진 다음의 6가지 REST 디자인 원칙에 맞아야 한다는 것입니다.
rest api의 6가지 원칙
- 균일한 인터페이스. 요청이 어디에서 오는지와 무관하게, 동일한 리소스에 대한 모든 API 요청은 동일하게 보여야 합니다. REST API는 사용자의 이름이나 이메일 주소 등의 동일한 데이터 조각이 오직 하나의 URI(Uniform Resource Identifier)에 속함을 보장해야 합니다. 리소스가 너무 클 필요는 없지만, 이는 클라이언트가 필요로 하는 모든 정보를 포함해야 합니다.
- 클라이언트-서버 디커플링. REST API 디자인에서, 클라이언트와 서버 애플리케이션은 서로 간에 완전히 독립적이어야 합니다. 클라이언트 애플리케이션이 알아야 하는 유일한 정보는 요청된 리소스의 URI이며, 이는 다른 방법으로 서버 애플리케이션과 상호작용할 수 없습니다. 이와 유사하게, 서버 애플리케이션은 HTTP를 통해 요청된 데이터에 전달하는 것 말고는 클라이언트 애플리케이션을 수정하지 않아야 합니다.
- Stateless. REST API는 stateless입니다. 이는 각 요청에서 이의 처리에 필요한 모든 정보를 포함해야 함을 의미합니다. 즉, REST API는 서버측 세션을 필요로 하지 않습니다. 서버 애플리케이션은 클라이언트 요청과 관련된 데이터를 저장할 수 없습니다.
- 캐싱 가능성. 가급적이면, 리소스를 클라이언트 또는 서버측에서 캐싱할 수 있어야 합니다. 또한 서버 응답에는 전달된 리소스에 대해 캐싱이 허용되는지 여부에 대한 정보도 포함되어야 합니다. 이의 목적은 서버측의 확장성 증가와 함께 클라이언트측의 성능 향상을 동시에 얻는 것입니다.
- 계층 구조 아키텍처. REST API에서는 호출과 응답이 서로 다른 계층을 통과합니다. 일반적으로는, 클라이언트와 서버 애플리케이션이 서로 간에 직접 연결된다고 가정하지 마세요. 통신 루프에는 다수의 서로 다른 중개자가 있을 수 있습니다. REST API는 엔드 애플리케이션 또는 중개자와 통신하는지 여부를 클라이언트나 서버가 알 수 없도록 설계되어야 합니다.
- 코드 온디맨드(옵션). REST API는 일반적으로 정적 리소스를 전송하지만, 특정한 경우에는 응답에 실행 코드(예: Java 애플릿)를 포함할 수도 있습니다. 이러한 경우에, 코드는 요청 시에만 실행되어야 합니다.
rest api의 작동 방식
REST API는 HTTP 요청을 통해 통신함으로써 리소스 내에서 레코드(CRUD 라고도 함)의 작성, 읽기, 업데이트 및 삭제 등의 표준 데이터베이스 기능을 수행합니다.
시간소인 또는 특정 인스턴트의 리소스 상태를 리소스 표현이라고 합니다. 이러한 정보는 JSON(JavaScript Object Notation), HTML, XLT, Python, PHP 또는 일반 텍스트를 포함하여 실제로 거의 모든 형식으로 클라이언트에 전달될 수 있습니다. JSON은 사람과 기계가 모두 읽을 수 있으므로 인기를 얻었으며, 이는 프로그래밍 언어와 무관한 언어입니다.
JSON.PACKAGE
NPM(Node Package Manager)
먼저, npm이 무엇인가?
npm(Node Package Manager)은 node.js를 위한 패키지 매니저이자, node.js를 위한 오픈소스 생태계이다.
package.json
You can add a package.json file to your package to make it easy for others to manage and install. Packages published to the registry must contain a package.json file.
lists the packages your project depends on
specifies versions of a package that your project can use using semantic versioning rules
makes your build reproducible, and therefore easier to share with other developers
(기본적으로는 package.json은 문서다.)
개발자가 배포한 패키지에 대해, 다른 사람들이 관리하고 설치하기 쉽게 하기 위한 문서.
npm에 패키지를 배포하고 npm registry에 올리기 위해서 반드시 필요한 문서파일이다.
자신의 프로젝트가 의존하는 패키지의 리스트
자신의 프로젝트의 버전을 명시
다른 환경에서도 빌드를 재생 가능하게 만들어, 다른 개발자가 쉽게 사용할 수 있도록 한다.
즉, npm이라는 오픈소스 패키지 생태계를 사용하기 위한 명세이자, 프로젝트의 의존성 관리를 위한 명세, 또 이 생태계로의 배포를 위한 명세라고 볼 수 있다.
위가 개발자가 직접 배포한 설명글이다. 풀어보면
프로젝트를 만들 때 프로젝트 패키지의 리스트와 버전을 명시해 놓고 그걸 재 사용 할 수 있게 저장하여 NPM이라는 오픈소스 패키지 생태계를 사용할 수 있게(사용하기 용이하게) 해주는 패키지 이며 이 역할을 통해 배포도 용이하게 만들어주는 좋은 저장, 배포 도구라고 할 수 있겠다.
