1-1. RESTful한 API의 개념
RESTful API는 Representational State Transfer의 약자로, 웹 표준을 활용하여 시스템 간의 상호 운용성을 제공하는 방법입니다. REST는 자원(Resource)의 표현(Representation)에 의한 상태 전달을 의미하며, 웹의 기본적인 기술과 프로토콜을 사용합니다.
왜냐하면 RESTful API는 HTTP 프로토콜을 기반으로 하며, 웹에서 사용되는 기술과 규약을 그대로 활용하기 때문입니다. 이를 통해 웹 어플리케이션 또는 서비스 간에 정보를 쉽게 주고 받을 수 있습니다.
RESTful API의 핵심 원칙에는 자원의 식별, 메시지를 통한 자원의 조작, 자기 서술적 메시지, 애플리케이션 상태의 엔진으로서의 하이퍼미디어 등이 있습니다.
이러한 원칙을 통해 RESTful API는 플랫폼 독립적이며, 언어 독립적인 인터페이스를 제공합니다. 따라서, 다양한 환경에서의 상호 운용성이 보장됩니다.
따라서, RESTful API는 현대 웹 서비스에서 데이터 교환의 표준으로 자리 잡았습니다.
1-2. RESTful API 설계 원칙
RESTful API를 설계할 때는 몇 가지 핵심 원칙을 따라야 합니다. 첫째, 자원(Resource)의 식별입니다. 모든 자원은 고유한 URI를 가지며, 이를 통해 자원을 식별합니다.
왜냐하면 URI는 인터넷 상에서 자원을 고유하게 식별하고 위치를 지정하는 표준 방법이기 때문입니다. 둘째, 자원에 대한 행위는 HTTP 메서드(GET, POST, PUT, DELETE)를 통해 표현합니다.
이는 HTTP 프로토콜의 기본 메서드를 활용하여, 자원에 대한 CRUD(Create, Read, Update, Delete) 연산을 명확하게 표현할 수 있기 때문입니다.
셋째, 메시지는 자기 서술적이어야 합니다. 메시지 포맷과 HTTP 메서드 등을 통해 요청의 의도를 명확하게 할 수 있어야 합니다.
넷째, 애플리케이션의 상태는 Hypermedia를 통해 관리됩니다. 클라이언트는 Hypermedia 링크를 통해 애플리케이션의 상태를 전환할 수 있어야 합니다.
이러한 원칙을 준수함으로써, RESTful API는 확장성, 유지보수성, 재사용성 등을 높일 수 있습니다.
1-3. RESTful API의 장점
RESTful API는 다양한 장점을 가지고 있습니다. 첫째, HTTP 프로토콜을 기반으로 하기 때문에, 웹에서 널리 사용되는 기술과 호환됩니다. 이는 개발자가 쉽게 접근할 수 있으며, 기존 웹 인프라를 활용할 수 있다는 의미입니다.
왜냐하면 RESTful API는 웹의 기존 표준을 그대로 활용하기 때문입니다. 둘째, 플랫폼과 언어에 독립적입니다. RESTful API는 JSON, XML 같은 표준 포맷을 사용하여 데이터를 교환하기 때문에, 다양한 플랫폼과 프로그래밍 언어에서 사용할 수 있습니다.
셋째, 간단하고 이해하기 쉬운 인터페이스를 제공합니다. RESTful API는 URI로 자원을 식별하고, HTTP 메서드로 해당 자원에 대한 행위를 정의하기 때문에, API의 구조를 쉽게 이해할 수 있습니다.
넷째, 확장성과 재사용성이 뛰어납니다. RESTful API는 상태를 클라이언트에 저장하지 않는 Stateless 아키텍처를 따르기 때문에, 서버와 클라이언트가 독립적으로 확장될 수 있습니다.
이러한 장점으로 인해, RESTful API는 현대 웹 서비스 개발에서 널리 사용되고 있습니다.
2-1. 적절한 관심사 분리를 해야하는 이유
프론트엔드 개발에서 아키텍처를 설계하는 것은 애플리케이션의 유지보수성, 확장성 및 성능을 결정짓는 중요한 요소입니다. 특히, 관심사의 분리(Separation of Concerns, SoC)는 프론트엔드 아키텍처를 설계할 때 기본적으로 고려해야 하는 원칙 중 하나입니다.
관심사의 분리는 애플리케이션의 다양한 기능과 요소를 명확하게 분리하여 각각 독립적으로 관리할 수 있도록 하는 개념입니다. 이를 통해 코드의 가독성을 높이고, 오류를 줄이며, 다른 개발자와의 협업을 용이하게 합니다.
왜냐하면 각 기능과 요소가 서로 독립적으로 분리되어 있기 때문에, 한 부분의 변경이 다른 부분에 미치는 영향을 최소화할 수 있기 때문입니다.
예를 들어, 사용자 인터페이스(UI), 비즈니스 로직, 데이터 관리 등의 관심사를 분리함으로써, 각각의 부분을 독립적으로 개발하고 테스트할 수 있습니다.
이러한 분리는 특히 대규모 프로젝트나 여러 개발자가 협업하는 환경에서 그 중요성이 더욱 강조됩니다.
2-2. 적절한 관심사 분리의 구현
프론트엔드에서 관심사의 분리를 구현하는 방법은 다양합니다. 가장 일반적인 방법 중 하나는 모델-뷰-컨트롤러(MVC) 패턴을 사용하는 것입니다. MVC 패턴은 애플리케이션을 모델(데이터), 뷰(UI), 컨트롤러(비즈니스 로직)의 세 부분으로 분리합니다.
또 다른 접근 방식으로는 모델-뷰-뷰모델(MVVM) 패턴이 있습니다. MVVM 패턴은 데이터 바인딩을 통해 뷰와 모델 사이의 동기화를 자동화하며, 뷰모델이 뷰와 모델 사이의 중재자 역할을 합니다.
왜냐하면 MVC나 MVVM과 같은 패턴을 사용함으로써 개발자는 UI와 비즈니스 로직을 명확히 분리할 수 있으며, 각각의 컴포넌트를 독립적으로 관리하고 재사용할 수 있기 때문입니다.
이러한 패턴들은 프론트엔드 개발에서 코드의 구조를 명확하게 하고, 유지보수와 확장성을 향상시키는 데 큰 도움을 줍니다.
3. Settet를 무분별하게 사용하면 안되는 이유
엔티티에 Setter로 필드 상태를 변경하고 트랜잭션이 종료되면 변경감지에 의해 update문이 나가게 됩니다. 그런데 Controller, Service에서도 Setter를 호출하기 때문에 시스템이 복잡해진다면 운영시 해당 update문이 어디서, 누구에 의해 발생되었는지 추적하기 어렵게 되기 때문입니다.
4-1. DBMS와 SQL
DBMS란(DataBase Management System) 사용자와 데이터베이스 사이에서 사용자의 요구에 따라 정보를 생성해 주고 데이터베이스를 관리해 주는 소프트웨어입니다.
SQL이란(Strucured Query Language) 관계형 데이터베이스 관리 시스템의 데이터를 관리하기 위해 설계된 특수 목적의 프로그래밍 언어이며 관계형 데이터베이스 관리 시스템에서 자료의 검색과 관리, 데이터베이스 스키마 생성과 수정, 데이터베이스 객체 접근 조정 관리를 위해 고안되었습니다.
4-2. RDBMS
위에서 DBMS는 사용자와 데이터베이스 사이에서 사용자의 요구에 따라 정보를 생성해주고 데이터베이스를 관리해 주는 소프트웨어라고 설명을 했습니다. 또한 기존의 RDBMS에서의 저장 방식은 SQL에 의해 저장되고 있으며 정해진 스키마에 따라 데이터를 저장하여야 합니다. RDBMS에는 DBMS앞에 R이 붙어 있습니다. 이 R은(Relational)의 약자로 RDBMS는 관계형 데이터베이스 관리 시스템을 의미합니다. 이름과 같이 RDBMS는 RDB를 관리하는 시스템이며 RDB는 관계형 데이터 모델을 기초로 두고 모든 데이터를 2차원 테이블 형태로 표현하는 데이터베이스입니다. 관계형 데이터베이스(RDMBS)는 아래와와 같이 구성된 테이블이 다른 테이블들과 관계를 맺고 모여있는 집합체로 이해할 수 있습니다. 관계형 데이터베이스(RDMBS)에서는 이러한 관계를 나타내기 위해 외래 키(foreign key)라는 것을 사용합니다. 이러한 테이블간의 관계에서 외래 키를 이용한 테이블 간 Join이 가능하다는 게 RDBMS의 가장 큰 특징입니다.
4-3. NoSQL
NoSQL이란(Not Only SQL)의 약자로 말 그대도 위에서 설명한 RDB 형태의 관계형 데이터베이스가 아닌 다른 형태의 데이터 저장 기술을 의미하고 있습니다. 또한 NoSQL에서는 RDBMS와는 달리 테이블 간 관계를 정의하지 않습니다. 데이터 테이블은 그냥 하나의 테이블이며 테이블 간의 관계를 정의하지 않아 일반적으로 테이블 간 Join도 불가능합니다. NoSQL은 점점 빅데이터의 등장으로 인해 데이터와 트래픽이 기하급수적으로 증가함에 따라 RDBMS에 단점인 성능을 향상시키기 위해서는 장비가 좋아야 하는 Scale-Up의 특징이 비용을 기하급수적으로 증가시키기 때문에 데이터 일관성은 포기하되 비용을 고려하여 여러 대의 데이터에 분산하여 저장하는 Scale-Out을 목표로 등장하였습니다.
NoSQL을 하면 가장 유명한 Document 기반의 MongoDB를 많이 떠올리지만 MongoDB는 NoSQL한 종류로 NoSQL은 하기와 같이 다양한 형태의 저장 기술을 지원하고 있습니다.
이 다양한 형태의 저장기술은 RDBMS 스키마에 맞추어 데이터를 관리해야 된다는 한계를 극복하고 수평적 확장성(Scale-out)을 쉽게 할 수 있다는 장점을 가지고 있습니다.
4-4. RDBMS의 장단점
장점: 정해진 스키마에 따라 데이터를 저장해야 하므로 명확한 데이터 구조를 보장합니다. 또한 각 데이터를 중복없이 한번만 저장할 수 있습니다.
단점: 테이블 간 테이블 관계를 맺고 있어 시스템이 커질 경우 Join문이 많은 복잡한 쿼리로 만들어질 수 있습니다.
성능 향상을 위해서 서버의 성능을 향상시켜야 하는 Scale-up만 지원합니다. 이로 인해 비용이 기하급수적으로 늘어납니다. 스키마로 인한 데이터가 유연하지 못합니다. 나중에 스키마가 변경될 경우 번거롭고 어렵게 됩니다.
4-5. NoSQL의 장단점
장점: 스키마가 없기 떄문에 유연하며 자유로운 데이터 구조를 가집니다.언제든 저장된 데이터를 조정하고 새로운 필드를 추가할 수 있습니다.
데이터 분산이 용이하며 성능 향상을 위한 Scale-up뿐만 아니라 Scale-out도 가능합니다.
단점: 데이터 중복이 발생할 수 있으며 중복된 데이터가 변경될 경우 모든 컬렉션에서 수정을 수행해야 합니다.
스키마가 존재하지 않기에 명확한 데이터 구조를 보장하지 않으며 데이터 구조 결정이 어려울 수 있습니다.
4-6. RDBMS와 NoSQL의 사용
RDBMS는 데이터 구조가 명확하며 변경 될 여지가 없으며 명확한 스키마가 중요한 경우 사용하는 것이 좋습니다. 또한 중복된 데이터가 없어(데이터 무결성) 변경이 용이하기 때문에 관계를 맺고 있는 데이터가 자주 변경이 이루어지는 시스템에 적합합니다.
NoSQL은 정확한 데이터 구조를 알 수 없고 데이터가 변경/확장이 될 수 있는 경우에 사용하는 것이 좋습니다. 또한 단점에서도 명확하듯이 데이터 중복이 발생할 수 있으며 중복된 데이터가 변경될 시에는 모든 컬렉션에서 수정을 해야 합니다. 이러한 특징들을 기반으로 Update가 많이 이루어지지 않는 시스템이 좋으며 또한 Scale-out이 가능하다는 장점을 활용해 막대한 데이터를 저장해야 해서 Database를 Scale-Out를 해야 되는 시스템에 적합합니다.
5-1. 객체지향 프로그래밍이란?
소프트웨어 개발에서 사용되는 프로그래밍 패러다임 중 하나로, 현실 세계의 사물을 모델링하여 소프트웨어를 개발하는 방법입니다.
- 클래스와 객체: 클래스는 객체를 생성하기 위한 템플릿이며, 객체는 클래스의 인스턴스입니다. 객체는 데이터와 해당 데이터를 처리하기 위한 메서드를 포함합니다.
- 상속: 상속은 하위 클래스가 상위 클래스의 특성과 메서드를 상속받는 개념입니다. 이를 통해 코드의 재사용성을 높일 수 있습니다.
- 다형성: 다형성은 같은 이름의 메서드가 다양한 형태로 작동할 수 있는 능력을 가리킵니다. 이는 상위 클래스에 정의된 메서드가 하위 클래스에서 다르게 구현될 수 있음을 의미합니다.
- 캡슐화: 캡슐화는 객체의 데이터와 메서드를 하나로 묶는 개념으로, 외부에서의 접근을 제어함으로써 데이터를 보호하고 은닉합니다.
이와 같은 개념을 포함합니다.
5-2. 객체지향 프로그래밍 사용의 이점
- 코드 재사용성: 상속을 통해 코드를 재사용할 수 있으며, 이는 개발 시간을 단축시키고 코드의 유지 보수를 용이하게 합니다.
- 유연성과 확장성: 다형성을 통해 유연하고 확장 가능한 코드를 작성할 수 있으며, 새로운 기능을 쉽게 추가할 수 있습니다.
- 유지 보수성: 캡슐화를 통해 데이터를 보호하고, 변경이 용이한 모듈화된 구조를 제공하여 코드의 유지 보수를 간편하게 할 수 있습니다.
- 대규모 프로젝트 관리: 객체지향 프로그래밍은 대규모 프로젝트를 효과적으로 관리할 수 있도록 돕습니다. 각 객체는 독립적으로 작동하며, 이는 프로젝트의 복잡성을 줄여줍니다.