항해 21일)Week03 회고록: Restful API, package.json

Nodel.js 3-1 주특기 입문 주차 마무리 회고록이다. 처음 강의를 보고 강의에서 만든 템플릿을 수정하는 방향으로 프로젝트를 시작했다. 수업에서 나오지 않은 프론트단 연결에서 많은 시간이 할애되었고 그 결과 api 오류 수정할 시간이 부족해 미완성으로 제출했다. 많이 아쉽지만 이번에 시작한 3-2심화주

 배운 것 / 느낀것 / 내게 아쉬웠던 것

배운것

1. Node를 이용한 웹 프레임워크 구성
2. MongoDB와 Mongoose를 이용한 DB생성, 활용
3. express 기반 CRUD기능이 포함된 REST API 구현
4. AWS에 express, MongoDB 서비스 배포
5. 프론트 - HTML

 

느낀 것

강의를 보고 나서 막상 만들려니 막막했다. 그래도 차분히 기획을 했고 3-2심화주차엔 좀 더 빠르게 해야겠다.

지금은 내가 베이스부터 프로젝트를 진행하는 것보다 남의 완성 코드를 보고 따라서 만들되 그 코드를 파악한 채 사용하는 것이 더 중요하다.

하나하나 디테일을 파악하는 것보다 우선 ①전체적인 흐름을 파악하고  ②코드를 하나하나 뜯어보며 HTTP메서드 별 코드 작성 방법을 파악하고   ③api별 기능 구현에 필요한 세부내용 기획한 후     ④기능을 구현한다. 

 

내게 아쉬웠던 것

완성된 코드를 수정하는 것은 그 코드를 다 파악한 사람만 할 수 있다는 걸 왜 까먹었을까,,, 여기서 시간이 너무 많이 소모됐다.

---

이번 WIL의 키워드

• Node.js : Restful API, package.json

 

 

 

Restful API (Representational State Transfer)

RESTful

REST API를 사용한 주소 체계를 RESTful 하다고 표현한다. 즉, REST 원리를 따르는 시스템은 RESTful이란 용어로 지칭된다. 공식적으로 발표된 것은 아니다.

 

RESTful의 목적
이해하기 쉽고 사용하기 쉬운 REST API를 만드는 것
RESTful 한 API를 구현하는 근본적인 목적이 성능 향상에 있는 것이 아니라 일관적인 컨벤션을 통한 API의 이해도 및 호환성을 높이는 것이 주 동기이니, 성능이 중요한 상황에서는 굳이 RESTful한 API를 구현할 필요는 없다.

 

RESTful 하지 못한 경우
Ex1) CRUD 기능을 모두 POST로만 처리하는 API
Ex2) route에 resource, id 외의 정보가 들어가는 경우(/students/updateName)

 

 

REST API  (Representational State Transfer)

소프트웨어 프로그램 개발의 아키텍처의 한 형식.

REST는  Representational State Transfer의 약자로서, 월드와이드 웹(www)과 같은 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처 중 하나의 형식이다. REST 서버는 클라이언트로 하여금 HTTP 프로토콜을 사용해 서버의 정보에 접근 및 변경을 가능케 한다. 여기서 정보는 text, xml, json 등 형식으로 제공한다.

• 클라이언트 서버 간에 데이터를 주고 받는 방식이다.
• HTTP URL(Uniform Resource Identifier)를 통해 데이터(자원)을 명시하고 Method(GET,POST,PUT,DELETE)를 통해 해당 데이터를 CRUD(Create,Read,Update,Delete)한다고 생각하면 된다.

REST를 정의하기 위한 조건

• '클라이언트-서버' 구조: 자원(resource)이 있는 쪽이 서버가 되며, 요청을 하는 쪽이 해당 서버에 대한 클라이언트가 된다.
• 무상태(Stateless): '서버'는 각각의 요청을 완전히 별개의 것으로 인식하고 처리해야하며, 이전 요청이 다음 요청의 처리에 연관이 되어서는 안됩니다. 즉 서버 session을 사용해선 안된다. 서버의 처리 방식에 일관성을 부여하고 서버의 부담을 줄이기 위한 것으로 보인다.
• 캐시 처리 가능(Cacheable): 대량의 요청을 효율적으로 처리하기 위해 캐시가 요구된다.
• 계층화(Layered System)
• Code on demand (optional)
• 인터페이스 일관성

 

 

1). 클라이언트 측 REST API

• GET (조회)
  • GET Method 에는 데이터를 조회하는 데 사용한다.
• POST (생성)
  • POST Method는 데이터를 생성할 때 사용한다. 보통 Body 데이터를 담아서 전송한다.
• PUT (전체 데이터 수정)
  • PUT Method는 전체 데이터를 수정할 때 사용한다. 보통 Body에서 수정할 데이터를 담아서 전송한다.
• PATCH (단일 데이터 수정)
  • PATCH Method는 단일데이터를 수정할 때 사용된다. Query Params나 Path Variables 와 Body를 혼합해 사용한다.
• DELETE (삭제)
  • DELETE Method 는 데이터를 삭제할 때 사용한다. 보통 Query Params 나 Path Variables를 잘 사용한다.

 

 

2). 서버 측 REST API

클라이언트 측 요청에 대한 서버의 응답은 두 부분으로 구분할 수 있다.
헤더와 바디, 바디는 Json 타입으로 응답하는 것이다. 헤더의 상태 코드 (Status Code)를 잘 사용하면 다양한 정보를 담아 클라이언트에게 전송할 수 있다.

응답 헤더의 상태 코드는 세 자리 정수로 되어있는데 크게 세 분류가 있다.

• 2XX - 성공
  • 201 - Created POST 메소드로 요청 시 서버 쪽에서 자원 생성에 성공하면 201 코드를 클라이언트로 응답
  • 204 - No Content 서버에서 성공했는데 응답할 바디가 없는 경우
• + 200 - **Success** 대부분의 성공 응답에 200 코드를 사용
• 4XX - 클라이언트 요청 에러
  • 401 - Unauthorized 인증이 필요한 API에 대해 인증되지 않은 요청일 경우
  • 403 - Fobbiden 401과 유사하면서 사용 방법에 대한 해석은 개발자마다 다르다
  • 404 - Not found 조회할 자원이 서버에 없는 경우 응답하는 코드
  • 409 - Conflict 클라이언트에서 POST메소드로 서버에서 자원 추가를 요청했을 때 이미 그 자원이 서버에 있어서 자원을 추가할 수 없는 경우.
• + 400 - **Bad Request** 클라이언트에서 파라미터를 포함해 서버 API를 요청하는데 파라미터가 잘못되었을 경우 응답하는 코드
• 5XX - 서버 응답 에러
  • 503 - Service Unavailable 서버가 과부하 상태 / 점검 상태 일시적으로 요청 처리 불가
  • 504 - Gateway Timeout 서버를 통하는 게이트웨이에 문제 발생하여 시간 초과
  • 505 - HTTP Version Not Supported 해당 HTTP 버전에서는 지원되지 않는 요청임을 알림
• + 500 - **Internal Server Error** 서버에서 클라이언트 요청 처리 중 에러

package.json

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

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

 

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	실행 가능한 노드 버전의 범위를 결정합니다.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

참고

*Rest api란

https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html

*package.json

package.json - 한눈에 끝내는 Node.js (goorm.io)

* Restful API - Koras02 코딩 웹

토막글: REST와 RESTful API - A MEAN Blog (a-mean-blog.com)

https://koras02.tistory.com/27 

[ Node.js ] - Restful API (velog.io)

https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html
[Node.JS] 강좌 10-2편: Express 프레임워크 응용하기 – RESTful API 편 | VELOPERT.LOG