[항해99] Week 03 회고 / Restful API, package.json

[

일기 쓸 예정

];

---

Restful API

 

What is REST (restfulapi.net)

 

간단히 말해 REST 아키텍처 스타일에서 데이터와 기능은 리소스로 간주되며 URI(Uniform Resource Identifier)를 사용하여 액세스합니다.

리소스는 단순하고 잘 정의된 작업 세트를 사용하여 작동합니다. 또한 클라이언트가 HTML, XML, 일반 텍스트, PDF, JPEG, JSON 등과 같은 다양한 형식의 컨텐츠에 액세스할 수 있도록 리소스를 표현에서 분리해야 합니다.

클라이언트와 서버는 표준화된 인터페이스와 프로토콜을 사용하여 리소스 표현을 교환합니다. 일반적으로 HTTP가 가장 많이 사용되는 프로토콜이지만 REST는 이를 강제하지 않습니다.

리소스에 대한 메타데이터는 캐시를 제어하고, 전송 오류를 탐지하고, 적절한 표현 형식을 협상하고, 인증 또는 액세스 제어를 수행하는 데 사용할 수 있습니다.

그리고 가장 중요한 것은 서버와의 모든 상호 작용은 상태 비저장 상태여야 한다는 것입니다.

이러한 모든 원칙은 RESTful 애플리케이션을 단순하고 가볍고 빠르게 만드는 데 도움이 됩니다.

 

---

REST API Naming Guide

 

 

 

REST Resource Naming Guide (restfulapi.net)

REST Resource Naming Guide

 

1. 동사보다는 명사 사용하기because nouns have properties that verbs do not have – similarly, resources have attributes
   • document 리소스를 나타낼 때는 ‘단수형’ 이름을 사용
   • collection 리소스를 나타낼 때는 ‘복수형’ 이름을 사용(collection 리소스는 서버가 관리하는 리소스 디렉토리)
   • store 리소스를 나타낼 때는 ‘복수형’ 이름을 사용(store는 클라이언트 관리 리소스 레파지토리)
   • controller는 동사를 사용 (get, post 등)
2. 리소스는 속성을 가지듯 명사는 동사와 달리 성질을 갖기 때문이다.
3. 일관성
4. 가독성과 유지보수성을 극대화 하고 모호함을 최소화 하기 위해 리소스의 네이밍과 URI의 형식은 일관되게 사용해야 한다.
5. 파일 확장자명 사용하지 않기
6. 이를 제거하면 URI의 길이도 줄어든다. 사용할 이유가 없다.
7. URI에 CRUD 이름 절대 사용하지 않기
8. URI는 리소스를 고유하게 식별할 때만 사용하고 리소스에 관한 어떤 작업도 하면 안된다.
9. URI 컬렉션을 필터 하기 위해 쿼리 구성 요소를 사용
10. 정렬, 필터링 등을 할 때 이를 위해 새 API를 사용하는 대신 쿼리문을 사용

---

packge.json

노드로 확장 모듈을 작성하면 npm을 통해 중앙 저장소로 배포할 수 있습니다. package.json 파일은 배포한 모듈 정보를 담고자 만들어졌지만, 노드로 작성하는 애플리케이션도 package.json 파일을 사용하여 관리할 수 있습니다. 꼭 확장 모듈 형태로 배포하기 위한 것이 아니더라도 애플리케이션을 개발할 때 package.json 파일을 이용하면 사용하는 확장 모듈에 대한 의존성 관리가 가능하기 때문에 편리합니다. 

pacakge.json 파일은 기본적으로 CommonJS의 명세를 충실히 따르고 있으며 JSON 형식의 파일입니다.

직접 작성할 수도 있고 npm init 명령을 통해서 자동으로 생성할 수도 있습니다. 그리고 해당 애플리케이션을 위해 사용한 확장 모듈에 대한 정보는 npm install -save를 통해 자동으로 모듈에 대한 정보를 추가할 수 있습니다.

다음은 package.json 파일의 내용과 설명입니다. 기본적으로 프로젝트에 대한 명세라고 할 수 있습니다.

 

{
	"name" : "test",
	"description" : "javascript's test programming.",
	"keywords" : ["util", "f", "server", "client", "browser"],
	"author" : "Goorm",
	"contributors" : [],
	"dependencies" : [],
	"repository" : {"type": "git", "url" : "git://gitbub.com/documentcloud/test.git" },
	"main" : "test.js",
	"version" : "1.1.6"
}

 

 

Key	Value
name	프로젝트 이름으로, 가장 중요합니다. 중앙 저장소에 배포할 때 version과 함께 필수 항목입니다. url로 사용되고, 설치할 때 디렉토리 이름이 되기 때문에 url이나 디렉터리에서 쓸 수 없는 이름을 사용하면 안 됩니다. 또한, 이름에 node나 js가 들어가면 안 됩니다. name은 214자보다 짧아야 하며, 점(.)이나 밑줄(_)로 시작할 수 없습니다. 대문자를 포함해서는 안 되며, require() 함수의 인수로 사용되며 짧고 알기 쉬운 것으로 짓는 것이 좋습니다.
version	프로젝트 버전을 정의합니다. 3단계 버전을 사용하며, - 로 태그 이름을 적을 수 있습니다.
description	프로젝트 설명으로, 문자열로 기술합니다. npm search로 검색된 리스트에 표시되기 때문에 사람들이 패키지를 찾아내고 이해하는 데 도움이 됩니다.
keywords	프로젝트를 검색할 때 참조되는 키워드입니다. description과 마찬가지로 npm search로 검색된 리스트에 표시됩니다.
homepage	프로젝트 홈페이지 주소입니다. url 항목과는 다르며, url을 설정하면 예상치 못한 움직임을 하게 되므로 주의합니다.
author	프로젝트 작성자 정보로, 한 사람만을 지정합니다. JSON 형식으로 name, email, url 옵션을 포함합니다.
contributors	프로젝트에 참여한 공헌자 정보로, 여러 사람을 배열로 지정할 수 있습니다.
repository	프로젝트의 소스 코드를 저장한 저장소의 정보입니다. 소스 코드에 참여하고자 하는 사람들에게 도움이 될 수 있습니다. 프로젝트의 홈페이지 url을 명시해서는 안 됩니다.
scripts	프로젝트에서 자주 실행해야 하는 명령어를 scripts로 작성해두면 npm 명령어로 실행 가능합니다.
config	소스 코드에서 config 필드에 있는 값을 환경 변수처럼 사용할 수 있습니다.
private	이 값을 true로 작성하면 중앙 저장소로 저장하지 않습니다.
dependencies	프로젝트 의존성 관리를 위한 부분입니다. 이 프로젝트가 어떤 확장 모듈을 요구하는지 정리할 수 있습니다. 일반적으로 package.json에서 가장 많은 정보가 입력되는 곳입니다. 애플리케이션을 설치할 때 이 내용을 참조하여 필요한 확장 모듈을 자동으로 설치합니다. 따라서 개발한 애플리케이션이 특정한 확장 모듈을 사용한다면 여기에 꼭 명시를 해주어야 합니다. 또한, npm install 명령은 여기에 포함된 모든 확장 모듈들을 설치하게 되어 있습니다.
devDependencies	개발할 때만 의존하는 확장 모듈을 관리합니다.
engine	실행 가능한 노드 버전의 범위를 결정합니다.