jh

리덕스란?

리덕스는 자바스크립트 어플리케이션 상태관리 라이브러리 이다. 특히 React와 함께 사용될때 유용하지만 다른 라이브러리와 프레임워크와도 사용이 가능하다.

리덕스는 하나의 상태를 하나의 저장소로 관리하며 이 저장소에 저장된 상태는 직접 수정이 불가능하고 오직 액션을 통해서만 변경될 수 있다. 액션은 상태 변경을 위한 명령어이며 어플리케이션에서 발생하는 모든 상태 변경은 이러한 액션을 통해 이루어진다. 액션을 처리하기 위해서는 리듀서를 이용해 이전 상태와 액션을 받아 새로운 상태를 반환하는 순수함수이다.

리덕스는 단방향 데이터 흐름을 따르기 때문에 상태 변화를 예측하기 쉽고, 디버깅도 용이하다. 또한 여러 컴포넌트 간의 상태를 공유하거나 상태 변경 로직을 중앙 집중화하여 관리하기 때문에 코드 유지보수성을 높여준다.

https://summerr.tistory.com/56

 MVC  pattern

프로그래밍 개발에는 여가지 디자인 패턴이 존재한다 . 

그 중에서 리덕스와 관련있는  Flux패턴과 그와 반대되는 MVC 패턴에 대해서 알아보자 

 MVC Pattern (Model View Controller Pattern )

MVC는 양방향으로 데이터가 흐르고,  규모가 커질수록  Controller의 규모가 커지면서 View 와 Model사이의 복잡도와 Model들간의 종속 업데이트로 개발이 어려워 질수 있다. 

이 패턴을 사용해 왔지만 규모가 커지면 수많은 view와 model들이 생기고 이것들을 파악하기 어렵게되어, 페이스북에서  Flux라는 패턴에 대해서 발표했다.  

Flux Pattern 

Flux 패턴은  단방향 데이터 흐름으로, 어떤 액션이 발생 하면 dispatcher에 의해 스토어에 변경된 사항이 저장 된다. 이 액션에 의해서 변경된 데이터들은 view에 반영되는 패턴이다.  Redux 라이브러리는 Flux 패턴을 채택하고 있다.  

Redux

리덕스는 상태관리를 공유하는것에 대해서 도움을 주는 라이브러리다. 리액트의 공식 문서를 보면 리덕스는 리덕스를 사용해야하는 때을 잘 판단하라고 설명 되어있다 . 

Pete Hunt -  "You'll know when you need Flux, if you aren't sure if you need it, you don't need it."
Dan Abramov - "I would like to amend this: don't use Redux until you have problems with vanilla React."
https://redux.js.org/faq/general#when-should-i-use-redux

 Redux를 사용해야하는 경우

- 규모가 큰 어플리케이션의 상태가 다른 컴포넌트들에게 필요한 경우

- 앱의 상태가 자주 업데이트 되는 경우 

- 상태를 업데이트하는 로직이 복잡할 경우

- 앱에 중간 또는 큰규모의 코드베이스가 있으며, 많은 사람들이 작업하는 경우 

- 시간이 지남에 따라 해당 상태가 어떻게 업데이트 되는지 확인이 필요한 경우

**리덕스를 꼭 필요할때 사용해야한다.**

리덕스는 꼭 리액트에서만 사용할수 있는가?

아닙니다. 리액트 공신 문서에 따르면, "가장 일반적인 용도는 React 및 React Native와 함께 사용되지만 Angular, Angular 2, Vue, Mithril 등에 사용할 수 있는 바인딩이 있습니다."

https://m.blog.naver.com/dlaxodud2388/222557737914

** 해결 **

REST API

HTTP 프로토콜 기반으로, 클라이언트와 서버 사이의 데이터 전송을 심플하고 효율적으로 통신을 위한 아키텍처 스타일이다. 


자원 (Resources): REST API는 서버에 존재하는 자원(데이터)들을 고유한 식별자(URI)로 표현합니다. 예를 들어, 사용자 정보를 나타내는 자원은 "/users"와 같은 URI로 표현될 수있다.

HTTP 메서드: REST API는 HTTP 메서드(GET, POST, PUT, DELETE 등)를 사용하여 자원에 대한 특정 작업을 수행한다. 예를 들어, GET 메서드는 자원을 조회하기 위해 사용되고, POST 메서드는 자원을 생성하기 위해 사용된다.

표현적인 상태 전송 (Stateless): REST API는 클라이언트와 서버 간의 상태를 유지하지 않는다. 각 요청은 독립적이며, 요청에 필요한 모든 정보는 요청 자체에 포함되어야 한다. 서버는 클라이언트의 요청을 이해하고 그에 따라 적절한 응답을 제공한다.


데이터 포맷: REST API는 일반적으로 JSON(JavaScript Object Notation)이나 XML(Extensible Markup Language) 형식으로 데이터를 전송한다. JSON은 가벼우며 읽기 쉽고 작성하기도 간편하기 때문에 널리 사용된다.

CREATE      POST      /user
READ.         GET.       /user/1
UPDATE      PUT.      /user/1
DELETE.      DELETE.  /user/1


REST 성숙도 모델

 
Level 0 : 1 URI, 1 HTTP method
level 0은 웹 메커니즘을 사용하지 않고 HTTP를 원격 통신을 위한 전송 시스템으로 사용한다. RPC(Remote Precedure Call) 형태로 리소스 구분 없이 설계된 HTTP API이다.
그저 단순하게 POX(Plain Old XML)를 주고 받는 RPC 스타일 시스템을 말한다. 단 하나의 endpoint를 사용하고, 전달되는 서로 다른 매개변수를 통해 하나의 endpoint에서 여러 동작을 하게 된다. 매개 변수를 body로 전달하기 위해 HTTP method는 POST가 된다.

RPC :  별도의 원격 제어를 위한 코딩 없이 다른 주소 공간에서 함수나 프로시저를 실행할 수 있게하는
  프로세스 간 통신 기술이다.

Level 1 : 
모든 자원은 개별 리소스에 맞는 엔드포인트(Endpoint)를 사용해야 하며 요청하고 받는 자원에 대한 정보를 응답으로 전달해야 한다는 것이 1단계의 핵심이다.
앞서 0단계에서는 요청에서의 엔드포인트로 모두 /appointment를 사용하였습니다. 하지만 1단계에서는 요청하는 리소스가 무엇인지에 따라 각기 다른 엔드포인트로 구분하여 사용한다 ex ) /appointment/1 

Level 2
CRUD에 맞게 적절한 HTTP 메서드를 사용하는 것에 중점을 둔다. 즉 어떤 리소스를 조회하는 행위를 하고 싶은 경우엔 GET 메서드를 사용하고, 어떤 리소스를 삭제하는 행위를 하고 싶은 경우엔 DELETE 메서드를 사용하는 등CRUD 에 맞는 적절한 HTTP 메서드를 통해 요청을 처리하면 됩니다.


참고 : https://oen-blog.tistory.com/211

Level 3

서비스를 HATEOAS(Hypertext As The Engine Of Application State, 애플리케이션 상태 엔진으로서의 하이퍼미디어) 원칙에 기반하여 설계한다. HATEOAS는 GET 요청으로 반환된 리소스 표현형에 그 리소스에 대한 액션의 링크도 함께 태워 보내자는 입니다. 가령 클라이언트는 GET 요청으로 주문 데이터를 조회하고 이때 반환된 표현형 내부 링크를 이용해서 해당 주문을 취소할 수도 있다. HATEOAS를 사용하면 하드 코딩한 URL을 클라이언트 코드에 욱여넣지 않아도 된다.






Open API & API Key


오픈API란 누구나 사용할 수 있도록 공개된 API를 말합니다. 데이터를 표준화하고 프로그래밍해 외부 소프트웨어 개발자나 사용자가 바로 개발(어프리케이션)에 활용할 수 있는 형태의 개방 형식입니다. 개방된 오픈API를 이용해 다양하고 재미있는 서비스나 애플리케이션, 다양한 형태의 플랫폼을 개발할 수 있습니다.
- 공공데이터 포털 -


오픈 API에 접근하기위해서는 api key를 얻어 접근하는 방법,  등(api key가 필요하지 않은 경우도 있다) 여러가지 방법있다. 


API Key 방식
가장 기초적인 방법은 API Key를 이용하는 방법이다. API Key란 특정 사용자만 알 수 있는 일종의 문자열이다. API를 사용하고자 할 때, 개발자는 API 제공사의 포탈 페이등 등에서 API Key를 발급 받고, API를 호출할 때 API Key를 메시지 안에 넣어 호출한다. 서버는 메시지 안에서 API Key를 읽어 이 API가 누가 호출한 API인지를 인증하는 흐름이다.
모든 클라이언트들이 같은 API Key를 공유하기 때문에 한번 API Key가 노출이 되면 전체 API가 뚫려 버리는 문제가 있기 때문에 높은 보안 인증을 요구 하는 경우에는 권장하지 않는다.


API Token 방식
다른 방식으로는 API Token을 발급하는 방식이 있는데, 사용자 ID,PASSWD등으로 사용자를 인증한 후에, 그 사용자가 API 호출에 사용할 기간이 유효한 API Token을 발급해서 API Token으로 사용자를 인증하는 방식이다.
매번 API 호출시 사용자 ID,PASSWD를 보내지 않고, API Token을 사용하는 이유는 사용자 PASSWD는 주기적으로 바뀔 수 있기 때문이고, 매번 네트워크를 통해서 사용자 ID와 PASSWD를 보내는 것은 보안적으로 사용자 계정 정보를 탈취 당할 가능성이 높기 때문에 API Token을 별도로 발급해서 사용하는 것이다.
API Token을 탈취 당하면 API를 호출할 수 는 있지만, 반대로 사용자 ID와 PASSWD는 탈취 당하지 않는다. 사용자PASSWD를 탈취당하면 일반적으로 사용자들은 다른 서비스에도 같은 PASSWD를 사용하는 경우가 많기 때문에 연쇄적으로 다른 서비스에 대해서도 공격을 당할 수 있는 가능성이 높아지기 때문이다. 예를 들어서 매번 호출시마다 사용자 ID,PASSWD를 보내서 페이스북의 계정과 비밀번호를 탈취 당한 경우, 해커가 이 계정과 비밀 번호를 이용해서 GMail이나 트위터와 같은 다른 서비스까지 해킹 할 수 있기 때문에, 이러한 가능성을 최소화하기 위함이다.