드디어 첫 미니프로젝트가 끝났다.
팀으로 진행되는 첫 end to end 프로젝트를 처음진행해 보았다.
기능들을 그 기술의 장단점을 고려하지 않고 기능을 구현하기 급급하기만 했었다.
마지막 설문에 jwt 방식이 무엇인지 쿠키/세션에 비해 jwt방식의 장점이 무엇이지? 서버사이드렌더링의 무엇이고 장점이 무엇인지 물어보는 질문에 뒤통수를 한대 맞은거 같았다.
프로젝트를 시작하며 사용할 기능들을 생각하고 그 기능에 사용되는 기술들을 찾아보고 장단점을 비교해가며 프로젝트를 진행해야 한다는 것을 느낀 미니 프로젝트였다.
프로젝트 진행상황 정리
Notion : https://www.notion.so/a9b85fdbf71047c7a57727fa2823f86a?v=e63d135f79b247999e5b40a3eb9fbdc0
프로젝트의 기능 구현의 경우는 깃헙으로 대체합니다.
github : DeveloperChoi90
찾아봐야 하는 것 : jwt 방식, 쿠키/세션, 서버사이드렌더링, TCP통신
기술검토/ 라이센스확인 필수
22.05.15
찾아본 것
JWT
- JSON Web Token의 약자로 전자 서명 된 URL-safe(URL로 이용할 수 있는 문자만 구성된)의 JSON이며 전자 서명은 JSON의 변조를 체크할 수 있게 되어있다.
- JWT는 속성 정보 (Claim)를 JSON 데이터 구조로 표현한 토큰으로 RFC7519 표준이다.
- JWT는 서버와 클라이언트 간 정보를 주고 받을 때 Http 리퀘스트 헤더에 JSON 토큰을 넣은 후 서버는 별도의 인증 과정없이 헤더에 포함되어 있는 JWT 정보를 통해 인증한다.
- JWT는 HMAC 알고리즘을 사용하여 비밀키 또는 RSA를 이용한 Public Key/ Private Key 쌍으로 서명할 수 있다.
- 프로젝트를 하며 JWT 방식을 사용한 이유
회원 인증:
사용자가 로그인을 하면, 서버는 사용자의 정보를 기반으로한 토큰을 발급한다.
그 후, 사용자가 서버에 요청을 할 때 마다 JWT를 포함하여 전달 서버는 클라이언트에서 요청을 받을때 마다, 해당 토큰이 유효하고 인증됐는지 검증을 한다. 사용자가 요청한 작업에 권한이 있는지 확인하여 작업을 처리한다.
서버에서는 사용자에 대한 세션을 유지 할 필요가 없습니다. 즉 사용자가 로그인되어있는지 안되어있는지 신경 쓸 필요가 없고, 사용자가 요청을 했을때 토큰만 확인하면 되므로 세션 관리가 필요 없어서 서버 자원과 비용을 절감할 수 있습니다.
참고 사이트 : http://www.opennaru.com/opennaru-blog/jwt-json-web-token/
API
- API는 애플리케이션 소프트웨어를 빌드하고 통합하기 위한 정의 및 프로토콜 세트인 애플리케이션 프로그래밍 인터페이스(Application Programming Interface)를 뜻한다.
이번 프로젝트를 진행한 형식은 flask framework를 사용한 REST(RESTful) API방식으로 진행되었다.
- REST API
REST API를 통해 요청이 수행될 때 REST API는 리소스 상태에 대한 표현을 요청자에게 전송한다. 이 정보 또는 표현은 HTTP: JSON(Javascript Object Notation), HTML, XLT 또는 일반 텍스트를 통해 몇 가지 형식으로 전송된다.
- REST 아키텍처의 제약 조건을 준수하는 웹 API를 RESTful API라고 합니다. SOAP는 프로토콜이지만 REST는 아키텍처 스타일이라는 근본적인 차이가 있으며 따라서 RESTful 웹 API에는 공식적인 표준이 없습니다. Roy Fielding의 논문인 '네트워크 기반 소프트웨어 아키텍처의 구조적 스타일과 설계(Architectural Styles and the Design of Network-based Software Architectures)'에 정의된 것처럼 RESTful 시스템의 다음 6가지 주요 제약 조건을 준수했을 때 RESTful API라고 간주할 수 있습니다.
- 클라이언트-서버 아키텍처: 클라이언트, 서버, 리소스로 구성된 REST 아키텍처이며 HTTP를 통해 요청을 처리합니다.
스테이트리스(Statelessness): 요청 후 다음 요청이 있을 때까지 클라이언트 콘텐츠가 서버에 저장되지 않으며 그 대신 세션 상태에 대한 정보가 클라이언트에 저장됩니다.
- 캐시 가능성: 캐싱으로 일부 클라이언트-서버 간 상호 작용을 대신할 수 있습니다.
- 계층화된 시스템: 추가 계층으로 클라이언트-서버 간의 상호 작용을 조정할 수 있으며 이러한 계층은 로드 밸런싱, 공유 캐시 또는 보안과 같은 추가 기능을 제공할 수 있습니다.
- 코드 온디맨드(옵션): 서버에서 실행 가능한 코드를 전송하여 클라이언트의 기능을 확대할 수 있습니다.
- 통합된 인터페이스: 이 제약 조건은 RESTful API 설계의 핵심이며 다음과 같은 4가지 측면을 포함합니다.
- 요청에서 리소스 식별: 리소스가 요청에서 식별되며 클라이언트로 반환되는 표현으로부터 분리됩니다.
- 표현을 통한 리소스 조작: 클라이언트가 리소스를 나타내는 파일을 수신합니다. 이 표현에는 조작 또는 삭제를 허용할 수 있도록 충분한 양의 정보가 포함되어야 합니다.
- 자기 기술적(Self-descriptive) 메시지: 클라이언트에 반환되는 각 메시지에는 클라이언트가 해당 정보를 어떻게 처리해야 할지 설명하는 정보가 충분히 포함되어야 합니다.
- 애플리케이션 상태 엔진으로서의 하이퍼미디어: REST 클라이언트는 리소스에 액세스한 후 하이퍼링크를 통해 현재 사용 가능한 다른 모든 작업을 찾을 수 있어야 합니다.
참고 사이트 : https://aws.amazon.com/ko/what-is/api/, https://www.redhat.com/ko/topics/api/what-are-application-programming-interfaces
