앱 개발을 고려한 Restful API 구현에 필요한 것들

최근 퇴사후 그누보드5용 svelte 빌더를 만들고 있습니다.

sveltekit 결과물이 spa 라는 특징으로 쉽게 하이브리드앱을 만들 수 있어서

얼마전 올려드린 그누보드5용 함수형 restful api에서 앱 환경에도 대응되도록 손을 보고 있습니다.

물론, 이렇게 하면, svelte 뿐만 아니라, react, vue, react native, flutter 모두 사용 할 수 있게 됩니다.

 속도도 빨라지고 spa, pwa 의 장점을 모두 활용할 수 있게 됩니다.

아래는 개발하면서 생각한 것들을 정리해 보았습니다.

라우팅 방식 결정

Restful API 구현해서 서비스를 하고 있는 다른 프레임워크들을 보면, 

라우팅 방식이 2가지로 나뉩니다.

1. 선언적 라우팅(제가 정한 이름입니다.)

 특정 파일에서 api 주소들을 나열하고 해당 주소가 호출되면 실행되는 모듈? 을 지정해줍니다.

 node express , rust actix 연습삼아 해봤는데, 선언적 라우팅을 사용하더라구요.

라우팅 주소를 마음대로 정할 수 있는 자율성과 한곳에서 관리할 수 있는게 장점인것 같습니다.

2. 파일베이스 라우팅

컨트롤러를 폴더와 파일에 만들고 그안에 컨트롤러 함수를 만들면 이를 기준으로 주소가 생성됩니다.

가장 익숙한 방식이죠.

그리고 sveltekit, next.js 에서도 파일베이스 라우팅을 사용하는걸 보니 가장 익숙한 방식이 갖는 장점은 여전히 진행형?

선언적 라우팅도 프로젝트 관리 차원상 폴더와 파일로 분리해서 관리할텐데, 굳이 선언적라우팅 파일을 만드는게 번거로운 일이 아닌가? 싶기도 하네요.

그래서 최근 만든 restful api 파일베이스 라우팅 방식으로 만들었습니다.

프론트와 백엔드 분리 이슈

1. 크로스 오리진 대응

프론트와 백엔드를 분리하다보면, 염두해두는 가정으로 앱 이 있습니다. 서버 주소와 앱의 주소는 다릅니다.

보안 정책상 요청주소와 서버주소를 수시로 확인합니다. 그래서 서로 다르면 보안기능이 작동하게 됩니다.

가. 에러처리

 header에 Access-Control-Allow-Origin: {접속브라우저 url 주소}

이 설정을 하지 않으면 에러가 납니다.

나. 쿠키 삭제

도메인이 다르다고 인지한 순간 쿠키가 삭제됩니다.

그래서 쿠키 의존 회원 인증 방식은 사용을 못합니다.

나는 쿠키 인증 사용안하고 세션방식이니까? 괜찮겠지? 그런데 세션도 쿠기 의존 인증방식입니다.

그래서 대안으로 나온게 jwt 인증입니다.

2. jwt 보안 이슈대응

대안으로 jwt 하면 끝나는게 아닙니다.

jwt가 그냥 대놓고 인증을 공개하는 방식입니다. 접속 컴퓨터에 악성코드 심어 놔서 저장되 토큰을 탈튀하면

보안 뚤립니다. 이렇게 위험한걸? 그런데, 세션방식, 쿠키방식도 동일한 상황입니다. 단, jwt는 베일에 가려져 있던

세션방식과 달리 공개적으로 운영방식을 확인할 수 있어서 보안 방식을 따져서 생각해볼수 있다는 차이가 있을 뿐입니다.

그래서 2중으로 보안을 추가하고 보안 레벨 방식을 적용합니다.

 가. refresh jwt 인증 추가

    access jwt는 15분간 유지시간을 두고, refresh jwt 토큰으로 access jwt 토큰을 15분마다 재발행하는 방식으로 access jwt탈퇴 되었을때 대응하도록합니다. refresh jwt는 한달간 유지시간을 두고 이증정보를 서버에 두고 접속 agent, ip 등으로 필터링합니다. 그럼 refresh jwt를 추가하면 보안이 완료되냐? 아닙니다. refresh jwt 토큰도 탈취되면 access jwt 와 같은 처지 입니다. 그래서 보안 레벨 정책과 최종 보안레벨은 개인 인증을 추가합니다.

 나. 2FA 인증

 몇년 전부터 결제나 본인인증하는 서비스를 보면 6자리 비번 등록해서 입력하라고 나오잖아요. 그게 이겁니다.

 안면 인식 인증, 지문인증, 패턴인증, 비번 인증 이런게 2차 인증입니다. 중요한 사안을 결정해야할때에는 2FA 인증을 추가해서   jwt 인증만으로 충족하지 못한 보안을 대응하도록하는 겁니다. 이건 비번한번 더 물어보는 것 만으로도 구현 될수도 있습니다. 그누보드에도 특정 행위시 비번 한번더 물어보는게 같은 맥락입니다. 결제할때는 외부 인증을 사용하고 말이죠.

 다. 보안 레벨 방식 적용

 jwt건 세션 방식이건 모두 쉽게 탈취 된다고 봅니다. 그래서 로그인 된 상태만 믿고 중요한일을 하면 안됩니다.

그래서 접근 레벨을 정하여 특정 행위시 보안레 벨별 인증을 추가 하도록 합니다.

탈취되어도 문제가 크지 않은 정보는 jwt 록그인 방식만으로 사용,  보안이 뚤리면 안되는 정보는 2FA 인증 사용, 그리고 수시로 jwt 탈취여부를 확인합니다.

 API 정보 문서화

swagger json 문서 생성이겠네요.

이건 json 파일을 만들어서 호출해도 되고

각 분리된 파일에서 주석형태로 만들어서 이를 취합해서 최종 json 형태로 출력되게 해도 됩니다.

서버운영 능력

일반 호스팅에 젖어서 너무 오랜 세월 길들여저 왔습니다. 그놈의 cafe24에 돈을 얼마나 벌어준겨ㅠㅠ

근데, cafe24에도 aws ec2 같은 서버클라우드가 있습니다. 최근에는 이것도 이용합니다. 또 cafe24네요.

apach 는 폴더에 .htaccess 파일만 올려두면 rewrite설정이 적용되어서 쉽게 주소 줄임기능 api 주소 구현이 됩니다.

그런데 nginx 는 도메인.conf 파일을 수정하고 웹서버 재시작을 해야해서 결국 일반 호스팅으로는 안되고

클라우드 서버 정도는 직접 운영해야 구현이 됩니다. 프론트는 어찌 어찌 Saas를 이용해도 되지만, 

겸사겸사 프론트도 node로 직접 돌려보려면, 서버 설정 정도는 다룰 수 있어야 합니다.

서버 비용상 인프라 형성 대응 순위를 보면

초기 Saas ,성장기 클라우드, 성숙기 물리서버 순으로 생각하실 텐데 

쉬운것 과 비용은 서로 반비레 하기 때문에 나중을 보시더라도 서버운영 능력은 갖추려고 노력하셔야 합니다.

Restful API 구현에서 주소 연결은  코드양으로 보면 약 10%정도.

줄임주소 기능이 어찌 보면 가장 큰 필요 조건입니다. Apache 나 Nginx의 rewrite 설정 말이죠.

그리고 특정 주소를 호출하면 어떤 함수를 호출해줄것인가의 방식고민에서 클래스, 함수형 이렇게 갈리는것 같습니다.

그리고 많은 부분은 프론트와 백엔드 분리 대응 부분이고 80%정도

나머지는 api 문서화 10% 정도