10장 웹 API 서버 만들기

노드는 자바스크립트 문법을 사용하므로 웹 API 서버에서 데이터를 전달할 때 사용하는 JSON을 100%활용하기에 좋다.

API 서버는 프런트엔드와 분리되어 운영되므로 모바일 서버로도 사용할 수 있다. 노드를 모바일 서버로 사용하려면 REST API 구조로 구성하면되는데 특히 JWT 토큰은 모바일 앱과 노드 서버 간에 사용자 인증을 구현할 때 자주 사용한다.

10.1 API 서버 이해하기

API

Application Programming Interface의 두문자어로, 다른 애플리케이션에서 현재 프로그램의 기능을 사용할 수 있게 허용하는 접점을 의미한다.

웹 API

다른 웹 서비스의 기능을 사용하거나 자원을 가져올 수 있는 창구.

웹 API 서버

서버에 API를 올려서 URL을 통해 접근할 수 있게 만든 것.

크롤링(Crawling)

웹 사이트가 자체적으로 제공하는 API가 없거나 API 이용에 제한이 있을 때 사용하는 방법

10.2 프로젝트 구조 갖추기

10장의 프로젝트는 NodeBird 서비스와 데이터 베이스를 공유한다. 새로 추가된 패키지는 uuid 이며, 고유한 랜덤 문자열을 만들어내는데 사용한다.

** type : Sequelize.ENUM('free', 'premium')
ENUM 이라는 속성은 넣을 수 있는 값을 제한하는 데이터 형식이다. 현재 위의 문장은 'free' or 'premium' 중에서 하나만 선택할 수 있게 지정한 것이며, 이를 어길경우 에러가 발생한다.

10.3 JWT 토큰으로 인증하기

JWT

JSON Web Token의 약어로 JSON 형식의 데이터를 저장하는 토큰.
JWT는 내용을 볼 수 있어서 민감한 내용을 넣으면 안된다. JWT는 다음과 같이 세 부분으로 구성되어 있다.

• 헤더(HEADER): 토큰 종류와 해시 알고리즘 정보가 들어있음
• 페이로드(PAYLOAD) : 토큰의 내용물이 인코딩된 부분
• 시그니처(SIGNATURE) : 일련의 문자열. 시그니처를 통해 토큰이 변조되었는지 여부를 확인할 수 있음
  ** 시그니처는 JWT 비밀 키로 만들어진다. 이 비밀 키가 노출되면 JWT 토큰을 위조할 수 있어서 비밀 키를 철저히 숨겨야한다. 하지만 시그니처 자체는 숨기지 않아도 된다.

JWT 토큰의 장점

1. JWT 토큰은 JWT 비밀 키를 알지 않는 이상 변조가 불가능하다.
   심지어 변조한 토큰은 시그니처를 비밀 키를 통해 검사할 때 들통난다. 변조가 불가능하므로 내용물의 변질에 대해 걱정할 필요가 없다.
2. 사용자 인증 권한을 최소화시킨다.
   비밀번호를 제외하고 사용자의 이메일이나 사용자의 권한 같은 것을 넣어두면 데이터베이스 조외없이도 그 사용자를 믿고 권한을 줄 수 있다.

JWT 토큰의 단점

1. 용량이 크다.
   내용물이 들어있으므로 랜덤한 토큰을 사용할 때와 비교하면 용량이 클 수밖에 없다.
2. 매 요청마다 데이터양이 증가한다.
   매 요청시 내용물이 들어있는 토큰들이 오고가므로 데이터양이 증가할 수밖에 없다.

10.4 다른 서비스에서 호출하기

API를 사용하는 서비스인 API 사용자의 입장에서 진행하는 서비스 만들어 보기.

가져온 데이터가 JSON 형태라면 퍼그나 넌적스 같은 템플릿 엔진으로 데이터를 렌더링 할 수 있다.

토큰에는 유효 기간이 있는데, 토큰을 발급해줄 때, 토큰이 만료되었을 경우 갱신하는 코드를 추가적으로 넣어줘야한다.

10.5 SNS API 서버 만들기

GET /post/my router : 내가 올린 포스트를 가져옴
GET /posts/hashtag/:title : 해시태그 검색 결과를 가져옴

10.6 사용량 제한 구현하기

인증된 사용자여도 과도하게 API를 사용하면 API서버에 무리가 간다. 이를 해결하기 위해서 일정 기간 내에 API를 사용할 수 이쓴 횟수를 제한하여 서버의 트래픽을 줄이는 것이 좋다.

이런 기능이 npm 패키지로 만들어져 있다. 바로 express-rate-limit 패키지.

// express-rate-limit 패키지 설치
$ npm i express-rate-limit

• API 응답 목록

  • 200 : JSON 데이터
  • 401 : 유효하지 않은 토큰
  • 410 : 새로운 버전 알림. 새로운 버전 사용 권장.
  • 419 : 토큰 만료
  • 429 : 1분에 한 번만 요청 가능
  • 500~ : 기타 서버 에러

10.7 CORS 이해하기

실제 서비스에서는 서버에 사용하는 비밀키와 프런트에서 사용하는 비밀키를 따로 두는 것이 좋다. 보통 서버에서 사용하는 비밀키가 강력하기 때문이다. 프런트에서 사용하는 비밀키는 모든 사람에게 노출된다.

CORS(Cross-Origin Resource Sharing)문제

브라우저와 서버의 도메인이 일치하지 않으면 기본적으로 요청이 차단된다. 이 현상은 브라우저에서 서버로 요청을 보낼 때만 발생하고, 서버에서 서버로 요청을 보낼 때는 발생하지 않는다.

CORS 문제 해결

응답 헤더에 Access-Control-Allow-Origin 헤더를 넣어야한다. 이 헤더는 클라이언트 도메인의 요청을 허락하겠다는 뜻을 가지고 있다. res.set 메서드로 직접 넣어도 되지만, npm에는 편하게 설치할 수 있도록 cors 패키지가 있다.

// cors 패키지 설치 명령어
$ npm i cors

CORS 옵션

• credentials: true
  // 이 옵션은 Access-Control-Allow-Credentials: true 로 만들어서 다른 도메인 간에 쿠키가 공유됨.
• Access-Control-Allow-Origin: *
  // 별(*)표시는 모든 클라이언트의 요청을 허락한다는 의미

10.8 프로젝트 마무리하기

• API는 다른 애플리케이션의 기능을 사용할 수 있게 해주는 창구이다.
• 모바일 서버를 구성할 때 REST API 방식으로 서버를 구현하면 된다.
• API 사용자가 API를 쉽게 사용할 수 있도록 사용 방법, 요청 형식, 응답 내용에 관한 문저를 준비한다.
• JWT 토큰의 내용은 공개되며 변조될 수 있다는 것을 기억해야한다. 하지만 시크니처를 확인하면 변조 여부를 확인할 수 있다.
• 토큰을 사용하여 API의 오남용을 막는다.
  요청 헤더에 토큰이 있는지를 항상 확인하는 것이 좋다.
• app.use 외에도 router.use를 활용하여 라우터 간에 공통되는 로직을 처리할 수 있다.
• CORS나 passport.authenticate 처럼 미들웨어 내에서 미들웨어를 실행할 수 있다. 미들웨어를 선택적으로 적용하거나 커스터마이징할 때 이 기법을 사용한다.
• 브라우저와 서버의 도메인이 다르면 요청이 거절되는 특성(CORS)을 이해하고 서버와 서버 간의 요청에서는 CORS 문제가 발생하지 않는다.