보안 이모저모

REST란?

REST(Representational State Transfer)는 분산 시스템을 설계하기 위한 소프트웨어 아키텍처 스타일로, 특히 HTTP 프로토콜을 기반으로 한 웹 서비스 설계에서 주로 사용됩니다. REST는 클라이언트와 서버 간 통신에서 리소스의 상태와 표현(Representation)을 전송한다는 개념에서 이름이 유래되었습니다.

REST의 등장

REST는 미국의 컴퓨터 과학자인 로이 필딩이 2000년 박사 논문에서 처음으로 제안되었습니다.  웹의 확장성과 상호운용성을 극대화하기 위해 정의된 아키텍처 스타일입니다.

하나의 브라우저만 지원하면 되었던 이전과는 달리 여러 브라우저, 멀티 플랫폼, 멀티 디바이스 시대가 되며 플랫폼들에 범용적으로 사용될 수 있는 서버 디자인이 필요하게 되었고, 이를 해결할 수 있는 아키텍처로 REST가 사용되고 있는것입니다.

어떻게?

REST api는 Client side의 플랫폼에 제약을 두지 않아야합니다. 그래서 Server side에선 Client side를 전혀 고려하지 않고 메시지 기반, XML, JSON과 같이 Client에서 객체로 치환가능한 형태의 데이터 통신을 지향하면서 Server와 Client의 역할을 분리하게 됩니다.

REST의 구성

• 자원(Resource) - URI
• 행위(Verb) - Http Method
• 표현(Representations)

1. 자원 (Resource) URI

모든 자원엔 고유한 ID가 존재하고, 이 자원은 Server에 존재합니다.

이 ID는 /product/3과 같은 HTTP URI의 형태로 구분합니다.

2. 행위 (Verb) - Http Method

Http프로토콜의 Method를 사용합니다.

Http Method는 POST, GET, PUT, DELETE가 있습니다.

3. 표현 (Representation of Resource)

Client가 자원의 상태(정보)에 대한 조작을 요청하면 Server는 이에 적절한 응답(Representation)을 보냅니다.

REST에서 하나의 자원은 JSON,XML,TEXT,RSS등 여러 형태의 응답을 받을 수 있습니다.

JSON혹은 XML을 통해 주고받는것이 일반적입니다.

REST의 제약조건

RESTful한 설계를 위해 아래와 같은 6가지 조건을 지켜야 합니다.

1) Client-Server(클라이언트-서버 구조) : 클라이언트와 서버를 명확히 분리하여 각자의 역할에 집중할 수 있도록 한다.

2) Stateless(상태 비저장성) : 서버는 클라이언트의 상태 정보를 저장하지 않는다. 각 요청은 독립적으로 처리되어야하며, 필요한 모든 정보는 요청에 포합되어야 한다.

3) Cacheable(캐시 처리 가능) : 서버 응답이 캐시될 수 있어야하며, 클라이언트는 이를 활용하여 네트워크 트래픽과 서버부하를 줄일 수 있다.

4) Code on demand(Optional) : 필요에 따라 서버가 클라이언트에 코드를 전송하여 실행할 수 있다. 예: Javascript, 플러그인 등

5) Uniform interface(인터페이스 일관성) : 일관된 인터페이스를 이용하여 모든 플랫폼에서 상호작용이 가능하도록한다. 특정 언어나 기술에 종속되지 않는다.

6) Layered System(계층화 시스템) : 클라이언트와 서버 간에 여러 계층을 둘 수 있으며, 각 계층은 독립적으로 동작한다.(예 :프록시 서버, 암호화 계층등)

RESTful API란?

Restful API는 REST의 설계 규칙을 잘 지켜서 설계된 API를 말합니다. 즉, REST API를 제공하는 서비스를 Restful 하다고 할 수 있습니다.

RESTful의 목적

이해하기 쉽고 사용하기 쉬운 REST API를 만드는 것, 일관적인 컨벤션을 통한 API의 이해도 및 호환성을 높이는 것이 주 목적입니다.

Reference

1. 디자인 패턴이란?

객체 지향 프로그래밍 설계를 할 때 자주 발생하는 문제들을 피하기 위해 사용되는 패턴. 개발을 하며 생길 수 있는 반복적인 문제들을 패턴을 통해 설계를 함으로써 미리 예방을 할 수 있게 됩니다..

디자인 패턴을 이용하면 유지보수성이 좋고 이해가 쉬운 코드를 짤 수 있게 됩니다.

2. MVC패턴이란?

MVC패턴은 데이터를 가지고 있는 Model, 사용자 인터페이스 요소를 가지고 있는 View, View와 Model을 이어주는  Controller의 3가지 요소로 나누어집니다.

이와 같이 3가지 요소로 나누어 사용자 인터페이스와 비즈니스 로직을 분리하여 코드의 의존성을 낮추고 유지보수성을 높이는 효과를 얻게 됩니다.

MVC의 작동은 다음과 같이 진행됩니다.

1. 사용자의 Request(요청)를 Controller가 받는다.
2. Controller는 비즈니스 로직을 처리한 후 결과를 Model에 담는다.
3. Model에 저장된 결과를 바탕으로 시각적 요소 출력을 담당하는 View를 제어하여 사용자에게 전달한다.

2.1 Model 모델

Model(모델)은 필요한 데이터에 대해서 Controller의 제어에 따라, DB에게 query를 하여 데이터를 저장, 삭제, 업데이트등을 진행하게 됩니다. View는 이 Model의 데이터를 기반으로 사용자 화면을 구성하게 됩니다.

Model의 상태에 변화가 있을 때 컨트롤러와 뷰에 이를 통보합니다. 이와 같은 통보를 통해서 뷰는 최신의 결과를 보여줄 수 있고, 컨트롤러는 모델의 변화에 따른 적용 가능한 명령을 추가·제거·수정할 수 있습니다. 어떤 MVC 구현에서는 통보 대신 뷰나 컨트롤러가 직접 모델의 상태를 읽어오기도 합니다.

모델의 규칙

2.2 View 뷰

View(뷰)는 사용자가 직접 보게되는 화면, 사용자 인터페이스를 구성하는 역할을 합니다.

뷰는 컨트롤러를 통해 받은 모델의 값을 통해 화면을 구성하게 됩니다.

뷰의 규칙

2.3 Controller 컨트롤러

Controller(컨트롤러)는 뷰와 모델의 사이를 잇는 인터페이스의 역할을 합니다.

모델이 데이터를 어떻게 처리할 것인지를 알려주고, 처리된 모델을 뷰에게 넘겨주게 됩니다.

모델이나 뷰로부터 변경 내용을 통지 받으면 이를 각 구성 요소에게 통지해야 합니다. 사용자가 어플리케이션을 조작하여 발생하는 변경 이벤트들을 처리하는 역할을 수행합니다.

컨트롤러의 규칙

3. MVC 패턴의 장점

• MVC패턴의 각 컴포넌트는 자신의 역할을 한 후 값을 넘겨주기만 하면 되기 때문에, 시스템 결합도가 낮아집니다.
• 각 코드가 여러파일에 나누어져 있기 때문에 코드의 가독성이 높아집니다.
• 유지보수 시 특정 컴포넌트만 수정하면 되기 때문에 유지보수가 쉬워집니다.

4. MVC 패턴의 한계

대규모 시스템의 경우 컨트롤러가 다수의 모델과 뷰를 컨트롤하여, 컨트롤러의 부담이 커지는 문제가 생기게 됩니다.

또한 다수의 뷰에 다수의 모델이 연결되는 경우가 생겨 서로간의 의존성이 커지는 경우가 발생할 수 있습니다.

이를 해결하기 위해 아래와 같은 패턴들이 있습니다.

• MVVM
• MVP
• MVW
• Flux
• Redux
• RxMVVM

Reference