Node.js Restful API

 

서버 데이터를 구조적으로 사용하기 위한 API디자인을 REST API라고 한다.
REST API 정리글

익스프레스는 노드를 만든 패키지의 일종으로 웹 서버를 만들기 위한 것이다.
클라이언트와 서버는 HTTP라는 규칙을 이용해서 서로 통신하게 되고, 웹에서도 이 HTTP를 이용해 페이지를 주고 받는다.
익스프레스가 웹 프레임워크이긴 하지만 똑같은 HTTP 기반의 API 서비스를 개발하는 것이기 때문에 API 서버에서도 사용하는 것이다. 또한 프레임워크를 사용하게 되면 노드로만 코드를 작성하는것 보다 훨씬 빠른시간에 효율적으로 서버를 개발할수 있는 이점이 있다.

send me email if you have any questions.


introduction

REST(Representational State Transfer)는 웹의 장점을 최대한 활용할 수 있는 아키텍처
최근의 서버 프로그램은 다양한 브라우저와 안드로이드폰, 아이폰과 같은 모바일 디바이스에서도 통신을 할 수 있어야 한다.
REST 아키텍처는 Hypermedia API의 기본을 충실히 지키면서 범용성을 보장한다.

REST의 특징

1. Uniform (유니폼 인터페이스)
Uniform Interface는 URI로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍처 스타일

2. Stateless (무상태성)
상태가 있다 없다는 의미는 사용자나 클라이언트의 컨택스트를 서버쪽에 유지 하지 않는다는 의미.
세션이나 쿠키등을 별도로 관리하지 않기 때문에 API서버는 요청만을 들어오는 메시지로만 처리하기 때문에 구현이 단순하다.

3. Cacheable (캐시 처리 가능)
REST의 가장 큰 특징 중 하나는 HTTP라는 기존 웹표준을 그대로 사용한다.
HTTP가 가진 캐싱 기능이 적용 가능하다. HTTP 프로토콜 표준에서 사용하는 Last-Modified태그나 E-Tag를 이용하면 캐싱 구현이 가능하다.

4. Self-descriptiveness (자체 표현 구조)
REST의 또 다른 큰 특징 중 하나는 REST API 메시지만 보고도 이를 쉽게 이해 할 수 있는 자체 표현 구조로 되어 있다는 것

5. Client - Server Architecture (클라이언트 - 서버 구조)
REST 서버는 API를 제공하고, 제공된 API를 이용해서 비즈니스 로직 처리 및 저장을 책임진다.
클라이언트의 경우 사용자 인증이나 컨택스트(세션,로그인 정보)등을 직접 관리하고 책임진다.
서로간의 의존성이 줄어들게 된다.

6. 계층형 구조
클라이언트 입장에서는 REST ApI 서버만 호출한다.
REST 서버는 다중 계층으로 구성될 수 있다. 예를 들어 보안, 로드 밸런싱, 암호화, 사용자 인증등등 추가하여 구조상의 유연성을 줄 수 있다.

REST API 규칙

1. URI는 정보의 자원을 표현해야 한다.
GET /course/insert/inform – X
GET /course/inform – O
HTTP Method (GET, PUT, POST, DELETE등등)의 행위가 URI 표현으로 들어가서는 안된다.

2. 자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE 등)로 표현
HTTP Method(GET, PUT, POST, DELETE등등)로 행위로 CRUD를 할 수 있다.

URI 설계 시 주의점

1) 슬래시 구분자(/)는 계층 관계를 나타내는 데 사용

https://limjunho.github.io
https://limjunho.github.io/about.html

2) URI 마지막 문자로 슬래시(/)를 포함하지 않는다.

https://limjunho.github.io --x

3) 하이픈(-)은 URI 가독성을 높이는데 사용
URI를 쉽게 읽고 해석하기 위해, 불가피하게 긴 URI경로를 사용하게 된다면 하이픈을 사용해 가독성을 높일 수 있다.

4) underscore(_)은 URI에 사용하지 않는다.
글꼴에 따라 다르긴 하지만 밑줄은 보기 어렵거나 밑줄 때문에 문자가 가려지기 하기 때문에 underscore(_) 대신 hyphen(-)을 사용하는 것이 좋다.

5) URI 경로에는 소문자가 적합하다.
URI 경로에 대문자 사용은 피하도록 해야 한다. 대소문자에 따라 다른 리소스로 인식하게 되기 때문.
RFC 3986(URI 문법 형식)은 URI 스키마와 호스트를 제외하고는 대소문자를 구별하도록 규정하고 있다.

6) 파일 확장자는 URI에 포함시키지 않는다.
REST API에서는 메시지 바디 내용의 포맷을 나타내기 위한 파일 확장자를 URI 안에 포함시키지 않는다.
Accept header를 사용하자.

HTTP 응답 상태 코드

잘 설계된 REST API는 URI만 잘 설계된 것이 아닌 그 리소스에 대한 응답을 잘 내어주는 것까지 포함되어야 한다.
정확한 응답의 상태코드만으로도 많은 정보를 전달할 수가 있기 때문에 응답의 상태코드 값을 명확히 돌려주는 것은 중요하다.

상태코드 내용
200 클라이언트의 요청을 정상 수행
201 클라이언트가 어떠한 리소스 생성을 요청, 해당 리소스가 성공적으로 생성
  (POST를 통한 리소스 생성 작업 시)


상태코드 내용
400 클라이언트의 요청이 부적절 할 경우 사용하는 응답 코드
401 클라이언트가 권한이 없는 자원(Resource)를 요청하였을 때 응답 코드
  (로그인 하지 않은 유저가 로그인 했을 때, 요청 가능한 리소스를 요청했을 때)
403 유저 인증상태와 관계 없이 응답하고 싶지 않은 리소스를 클라이언트가 요청했을 때 사용하는 응답 코드
  (403 보다는 400이나 404를 사용할 것을 권고. 403 자체가 리소스가 존재한다는 뜻이기 때문에)
405 클라이언트가 요청한 리소스에서는 사용 불가능한 Method를 이용했을 경우 사용하는 응답 코드


상태코드 내용
301 클라이언트가 요청한 리소스에 대한 URI가 변경 되었을 때 사용하는 응답 코드
  (응답 시 Location header에 변경된 URI를 적어 줘야 합니다.)
500 서버에 문제가 있을 경우 사용하는 응답 코드

install

$ npm init --yes
$ npm install express

express 설치

const express = require("express");
const app = express();

app.get();
app.post();
app.put();
app.delete();

express 기본 구조