2. 개발에 앞서 알면 좋은 지식
3장부터 시작하는 웹 애플리케이션 개발 프로젝트를 진해하기 전에 앞으로 도움이 될 내용들에 대한 설명이 들어있다.
해당 장에서는 Spring boot Application이 '어떻게 동작하는지', '왜 이렇게 구성되는지'에 초점을 두고 설명합니다.
2.1 서버 간 통신
어떤 웹 사이트를 하나의 서비스 단위로 개발한다고 가정해보자. 즉, 하나의 웹 사이트 내부에 블로그, 카페, 메일과 같은 기능을 하나의 애플리케이션에 통합하여 배포했다는 뜻입니다.
서비스를 이렇게 구성하게 되면 업데이트를 진행하거나 유지보수를 진행할 때, 개발자는 개발에 있어서 보수적인 입장을 취하게 될 것입니다. 또한, 서비스 자체의 규모도 커지기때문에 서비스를 구동하는 데 걸리는 시간도 길어집니다.
이러한 문제를 해결하기 위해서 나온 것이 Micro Service Architecture, MSA입니다.
MSA는 말 그대로 하나의 서비스를 여러가지의 서비스로 분리하여 구성한 아키텍쳐를 의미합니다.
위의 예시를 가져온다면, 블로그 서비스, 카페 서비스, 메일 서비스로 분리되고 연결되어 전체적인 서비스를 제공하게 될 것입니다.
A 포털 사이트처럼 개발할 시에는 내부 메서드 호출을 통해서 원하는 자원을 가져와 사용할 수 있지만, B 포털 사이트처럼 개발할 시에는 각 서비스 간에 통신해야 하는 경우가 발생합니다.
서버간 통신은 한 서버가 다른 서버에 통신을 요청하는 것을 의미하며, 한 대는 서버, 다른 한 대는 클라이언트가 되는 구조입니다.
gRPC와 같은 방식을 통해서 통신을 할 수도 있지만, 일반적으로 많이 사용하는 통신 방식에는 HTTP/HTTPS가 있습니다.
2.2 스프링 부트의 동작 방식
스프링 부트에서는 spring-boot-starter-web 모듈을 사용하면 내장 Tomcat WAS가 실행되고 MVC 구조를 기반으로 동작합니다.
Servelt(서블릿)은 클라이언트의 요청을 처리하고 결과를 반환하는 자바 웹 프로그래밍 기술입니다. 스프링 탄생 이전에 사요되었습니다.
일반적으로 서블릿은 서블릿 컨테이너에서 관리합니다. 서블릿 컨테이너는 서블릿 인스턴스를 생성하고 관리하는 역할을 수행하는 주체로서 Tomcat은 WAS의 역할과 서블릿 컨테이너의 역할을 수행하느 대표적인 컨테이너입니다.
서블릿 컨테이너의 특징은 다음과 같습니다.
- 서블릿 객체를 생성, 초기화, 호출, 종료하는 생명주기를 관리합니다.
- 서블릿 객체는 싱글톤 패턴으로 관리됩니다.
- 멀티 스레딩을 지원합니다.
스프링에서는 DispatcherServlet이 서블릿 역할을 수행합니다.
그림 2.2의 흐름을 간략하게 보면,
- DispatcherServlet으로 요청이 들어오면 DispatcherServlet은 핸들러 매핑을 통해 요청 URI에 매핑된 핸들러를 탐색합니다. 여기서 핸들러는 Controller를 의미합니다.
- 핸들러 어댑터로 컨트롤러를 호출합니다.
- 핸들러 어댑터에 컨트롤러의 응답이 돌아오면 ModelAndView로 응답을 가공해 반환합니다.
- 뷰 형식으로 리턴하는 컨트롤러를 사용할 때는 View Resolver를 통해 View를 받아 반환합니다.
핸들러 매핑은 요청 정보를 기준으로 어떤 컨트롤러를 사용할 지 선정하는 인터페이스입니다.
핸들러 매핑 인터페이스는 다음 사진과 같은 여러 구현체를 가집니다.
다음은 View를 반환하는 컨트롤러와 @ResponseBody를 사용해서 Json 형식으로 반환하는 컨트롤러의 흐름입니다.
2.3 Layered Architecture
레이어드 아키텍쳐(Layered Architecture)란 애플리케이션의 컴포넌트를 유사 관심사를 기준으로 레이어로 묶어, 수평적으로 구성한 구조를 의미합니다.
일반적으로 레이어드 아키텍쳐라고 하면 3계층 또는 4계층 구성을 의미합니다. 이 차이는 인프라 레이어의 추가 여부로 결정됩니다.
프레젠테이션 계층은 애플리케이션 최상단 계층으로, 클라이언트의 요청을 해석하고 응답하는 계층입니다. 또한, 별도의 비즈니스 로직을 포함하고 있지 않으므로 비즈니스 계층으로 요청을 위임하고 받은 결과를 응답하는 역할만 수행합니다.
비즈니스 계층은 애플리케이션이 제공하는 기능을 제공하고 세부 작업을 수행하는 도메인 객체를 통해 업무를 위임하는 역할을 수행합니다.
DDD(Domain Driven Design)기반의 아키첵쳐에서는 비즈니스 로직에 도메인이 포함되기도 하고, 별도의 도메인 계층을 두기도 합니다.
데이터 접근 계층은 데이터베이스에 접근하는 일련의 작업을 수행합니다.
Layered Architecture 기반 설계는 다음과 같은 특징을 지닙니다.
- 각 레이어는 가장 가까운 하위 레이어의 의존성을 주입받습니다.
- 각 레이어는 관심사에 따라 묶여 있으며, 다른 레이어의 역할을 침범하지 않습니다.
- 각 컴포넌트의 역할이 명확하므로 코드의 가독성과 기능 구현에 유리합니다.
- 코드의 확장성도 좋아집니다.
- 각 레이어가 독립적으로 작성되면 다른 레이어와의 의존성을 낮춰 단위 테스트에 용이합니다.
따라서 다음과 같은 모양을 띄게됩니다.
해당 사진은 일반적인 Layered Architecture를 스프링에 적용한 모습입니다.
특징은 비슷하긴하지만, 비즈니스 계층의 경우 때때로 서비스 계층이라고도 합니다. 해당 계층에서는 핵심 비즈니스 로직을 구현합니다.
추가적으로 트랙잭션 처리나 유효성 검사 등의 작업도 수행합니다.
또한, 데이터 접근 계층의 경우 상황에 따라 영속 계층이라고도 합니다.
2.4 디자인 패턴
디자인 패턴은 소프트웨어를 설계할 때 자주 발생하는 문제들을 해결하기 위해서 고안된 해결책입니다.
패턴이라는 단어는 애플리케이션 개발에서 발생하는 문제는 유사한 경우가 많고, 해결책도 동일하게 적용할 수 있다는 의미를 내포합니다.
하지만, 디자인 패턴이 모든 문제의 정답은 아니며, 상황에 맞는 최적 패턴을 결정해서 사용하는 것이 바람직합니다.
2.4.1 디자인 패턴의 종류
디자인 패턴을 구체화해서 정리한 대표적인 분류 방식으로 GoF 디자인 패턴이라는 것이 있습니다.
GoF란 'Gang of Four' 의 줄임말로, 디자인 패턴을 구체화하고 체계화해서 분류한 4명의 인물을 의미합니다.
GoF 디자인 패턴은 생성, 구조, 행위 패턴으로 총 3가지로 구분됩니다.
생성 패턴은 객체 생성에 사용되는 패턴으로 객체를 수정해도 호출부가 영향을 받지 않게하는 패턴입니다.
구조 패턴은 객체를 조합해서 더 큰 구조를 만드는 패턴입니다.
행위 패턴은 객체 간의 알고리즘이나 책임 분배에 관한 패턴입니다. 객체 하나로는 수행할 수 없는 작업을 여러 객체를 이용해 작업을 분배합니다. 결합도 최소화를 고려할 필요가 있습니다.
2.4.2 생성 패턴
추상 팩토리 : 구체적인 클래스를 지정하지 않고 상황에 맞는 객체를 생성하기 위한 인터페이스를 제공하는 패턴입니다.
빌더 : 객체의 생성과 표현을 분리해 객체를 생성하는 패턴입니다.
팩토리 메서드 : 객체의 생성을 서브클래스로 분리해서 위임하는 패턴입니다.
프로토타입 : 원본 객체를 복사해 객체를 생성하는 패턴입니다.
싱글톤 : 한 클래스마다 인스턴스를 하나만 생성해서 인스턴스가 하나임을 보장하고 어느 곳에서도 접근할 수 있게 제공하는 패턴입니다.
2.4.3 구조 패턴
어댑터 : 클래스의 인터페이스를 의도하는 인터페이스로 변환하는 패턴입니다.
브리지 : 추상화와 구현을 분리해서 각각 독립적으로 변형케 하는 패턴입니다.
컴포지트 : 여러 객체로 구성된 복합 객체와 단일 객체를 클라이언트에서 구별 없이 다루는 패턴입니다
데코레이터 : 객체의 결합을 통해 기능을 동적으로 유연하게 확장할 수 있게 하는 패턴입니다.
퍼사드 : 서브시스템의 인터페이스 집합들에 하나의 통합된 인터페이스를 제공하는 패턴입니다.
플라이웨이트 : 특정 클래스의 인스턴스 한 개를 가지고 여러 개의 '가상 인스턴스'를 제공할 때 사용하는 패턴입니다
프록시 : 특정 객체를 직접 참조하지 않고 해당 객체를 대행(프락시)하는 객체를 통해 접근하는 패턴입니다.
2.4.4 행위 패턴
책임 연쇄 : 요청 처리 객체를 집합으로 만들어 결합을 느슨하게 만드는 패턴입니다.
커맨드 : 실행될 기능을 캡슐화해서 주어진 여러 기능을 실행하도록 클래스를 설계하는 패턴입니다.
인터프리터 : 주어진 언어의 문법을 위한 표현 수단을 정의하고 해당 언어로 구성된 문장을 해석하는 패턴입니다.
이터레이터 : 내부 구조를 노출하지 않으면서 해당 객체의 집합 원소에 순차적으로 접근하는 방법을 제공하는 패턴입니다.
미디에이터 : 한 집합에 속한 객체들의 상호작용을 캡슐화하는 객체를 정의한 패턴입니다.
메멘토 : 객체의 상태 정보를 저장하고 필요에 따라 상태를 복원하는 패턴입니다.
옵저버 : 객체의 상태 변화를 관찰하는 관찰자들, 즉 옵저버 목록을 객체에 등록해 상태가 변할 때마다 메서드 등을 통해 객체가 직접 옵저버에게 통지하게 하는 디자인 패턴입니다.
스테이트: 상태에 따라 객체가 행동을 변경하게 하는 패턴입니다.
스트래티지: 행동을 클래스로 캡슐화해서 동적으로 행동을 바꿀 수 있게 하는 패턴입니다.
템플릿 메서드: 일정 작업을 처리하는 부분을 서브클래스로 캡슐화해서 전체 수행 구조는 바꾸지 않으면서 특정 단계만 변경해서 수행하는 패턴입니다.
비지터: 실제 로직을 가지고 있는 객체(visttor)가 로직을 적용할 객체(clement)를 방문하며 실행하는 패턴입니다.
2.5 REST API
REST API는 대중적으로 가장 많이 사용되는 애플리케이션 인터페이스입니다.
이 인터페이스를 통해 클라이언트가 서버에 접근하고 자원을 조작할 수 있습니다.
2.5.1 REST란?
REST란 Representational State Transfer의 약자로 WWW(World Wide Web)과 같은 분산 하이퍼미디어 시스템 아키텍쳐의 한 형식입니다. 주고받는 자원에 이름을 규정하고 URI에 명시해 HTTP 메서드를 통해 해당 자원의 상태를 주고받는 것을 의미합니다.
2.5.2 REST API란?
API는 Application Programming Interface로 애플리케이션에서 제공하는 인터페이스를 의미합니다.
API를 통해 서버 또는 프로그램 사이를 연결할 수 있습니다. 즉, REST API는 REST 아키텍쳐를 따르는 시스템/애플리케이션 인터페이스라고 할 수 있습니다.
2.5.3 REST의 특징
- Uniform Interface / 일관된 인터페이스
- REST 서버는 HTTP 표준 전송 규약을 따르기 때문에, 어떤 프로그래밍 언어로 작성되었느냐와 상관없이 플랫폼 및 기술에 종속되지 않고 타 언어, 프레임워크와 호환해 사용할 수 있다는 것을 의미합니다.
- Stateless / 무상태성
- REST는 무상태성이라는 특징을 가집니다. 무상태성이란 서버에 상태 정보를 따로 보관하거나 관리하지 않는다는 의미입니다. 서버는 클라이언트가 보낸 요청에 대해 세션이나 쿠키정보를 별도로 보관하지 않습니다. 때문에 한 클라이언트가 여러 요청을 보내든 여러 클라이언트가 각각 하나의 요청을 보내든 개별적으로 처리합니다. 이렇게 구성된 서비스는 서버가 불필요한 정보를 관리하지 않으므로 비즈니스 로직의 자유도가 높고 설계가 단순합니다.
- Cacheable / 캐시 가능성
- HTTP 캐싱 기능을 적용할 수 있습니다. 이 기능을 이용하기 위해서는 응답과 요청이 모두 캐싱 가능한지(Cacheable) 명시가 필요하며, 캐싱이 가능한 경우 클라이언트에서 캐시에 저장해두고 같은 요청에 대해서는 해당 데이터를 가져다 사용합니다. 이 기능을 사용하면 서버의 트랜잭션 부하가 줄어 효율적이며 사용자 입장에서 성능이 개선됩니다.
- Layered System / 레이어 시스템
- REST 서버는 네트워크 상의 여러 계층으로 구성될 수 있습니다. 그러나 서버의 복잡도와 관계없이 클라이언트는 서버와 연결되는 포인트만 알면 됩니다.
2.5.4 REST의 URL 설계 규칙
- URL의 마지막에는 "/"를 포함하지 않습니다.
- 언더바(_)는 사용하지 않습니다. 대신 하이픈(-)을 사용합니다.
- URL에는 행위(동사)가 아닌 결과(명사)를 포함합니다.
- URI는 소문자로 작성해야합니다.
- 파일의 확장자는 URI에 포함하지 않습니다.
'책' 카테고리의 다른 글
| [Book] 스프링 부트 핵심 가이드 Chap.4 (0) | 2024.06.25 |
|---|---|
| [Book] 스프링 부트 핵심 가이드 Chap.3 (0) | 2024.06.23 |
| [Book] 스프링 부트 핵심 가이드 Chap.1 (0) | 2024.06.23 |
| [데이터베이스 첫 걸음] 4주차 공부 내용 정리 (1) | 2023.10.17 |
| [데이터베이스 첫 걸음] 3주차 공부 내용 정리 (0) | 2023.10.17 |
2. 개발에 앞서 알면 좋은 지식
3장부터 시작하는 웹 애플리케이션 개발 프로젝트를 진해하기 전에 앞으로 도움이 될 내용들에 대한 설명이 들어있다.
해당 장에서는 Spring boot Application이 '어떻게 동작하는지', '왜 이렇게 구성되는지'에 초점을 두고 설명합니다.
2.1 서버 간 통신
어떤 웹 사이트를 하나의 서비스 단위로 개발한다고 가정해보자. 즉, 하나의 웹 사이트 내부에 블로그, 카페, 메일과 같은 기능을 하나의 애플리케이션에 통합하여 배포했다는 뜻입니다.
서비스를 이렇게 구성하게 되면 업데이트를 진행하거나 유지보수를 진행할 때, 개발자는 개발에 있어서 보수적인 입장을 취하게 될 것입니다. 또한, 서비스 자체의 규모도 커지기때문에 서비스를 구동하는 데 걸리는 시간도 길어집니다.
이러한 문제를 해결하기 위해서 나온 것이 Micro Service Architecture, MSA입니다.
MSA는 말 그대로 하나의 서비스를 여러가지의 서비스로 분리하여 구성한 아키텍쳐를 의미합니다.
위의 예시를 가져온다면, 블로그 서비스, 카페 서비스, 메일 서비스로 분리되고 연결되어 전체적인 서비스를 제공하게 될 것입니다.
A 포털 사이트처럼 개발할 시에는 내부 메서드 호출을 통해서 원하는 자원을 가져와 사용할 수 있지만, B 포털 사이트처럼 개발할 시에는 각 서비스 간에 통신해야 하는 경우가 발생합니다.
서버간 통신은 한 서버가 다른 서버에 통신을 요청하는 것을 의미하며, 한 대는 서버, 다른 한 대는 클라이언트가 되는 구조입니다.
gRPC와 같은 방식을 통해서 통신을 할 수도 있지만, 일반적으로 많이 사용하는 통신 방식에는 HTTP/HTTPS가 있습니다.
2.2 스프링 부트의 동작 방식
스프링 부트에서는 spring-boot-starter-web 모듈을 사용하면 내장 Tomcat WAS가 실행되고 MVC 구조를 기반으로 동작합니다.
Servelt(서블릿)은 클라이언트의 요청을 처리하고 결과를 반환하는 자바 웹 프로그래밍 기술입니다. 스프링 탄생 이전에 사요되었습니다.
일반적으로 서블릿은 서블릿 컨테이너에서 관리합니다. 서블릿 컨테이너는 서블릿 인스턴스를 생성하고 관리하는 역할을 수행하는 주체로서 Tomcat은 WAS의 역할과 서블릿 컨테이너의 역할을 수행하느 대표적인 컨테이너입니다.
서블릿 컨테이너의 특징은 다음과 같습니다.
- 서블릿 객체를 생성, 초기화, 호출, 종료하는 생명주기를 관리합니다.
- 서블릿 객체는 싱글톤 패턴으로 관리됩니다.
- 멀티 스레딩을 지원합니다.
스프링에서는 DispatcherServlet이 서블릿 역할을 수행합니다.
그림 2.2의 흐름을 간략하게 보면,
- DispatcherServlet으로 요청이 들어오면 DispatcherServlet은 핸들러 매핑을 통해 요청 URI에 매핑된 핸들러를 탐색합니다. 여기서 핸들러는 Controller를 의미합니다.
- 핸들러 어댑터로 컨트롤러를 호출합니다.
- 핸들러 어댑터에 컨트롤러의 응답이 돌아오면 ModelAndView로 응답을 가공해 반환합니다.
- 뷰 형식으로 리턴하는 컨트롤러를 사용할 때는 View Resolver를 통해 View를 받아 반환합니다.
핸들러 매핑은 요청 정보를 기준으로 어떤 컨트롤러를 사용할 지 선정하는 인터페이스입니다.
핸들러 매핑 인터페이스는 다음 사진과 같은 여러 구현체를 가집니다.
다음은 View를 반환하는 컨트롤러와 @ResponseBody를 사용해서 Json 형식으로 반환하는 컨트롤러의 흐름입니다.
2.3 Layered Architecture
레이어드 아키텍쳐(Layered Architecture)란 애플리케이션의 컴포넌트를 유사 관심사를 기준으로 레이어로 묶어, 수평적으로 구성한 구조를 의미합니다.
일반적으로 레이어드 아키텍쳐라고 하면 3계층 또는 4계층 구성을 의미합니다. 이 차이는 인프라 레이어의 추가 여부로 결정됩니다.
프레젠테이션 계층은 애플리케이션 최상단 계층으로, 클라이언트의 요청을 해석하고 응답하는 계층입니다. 또한, 별도의 비즈니스 로직을 포함하고 있지 않으므로 비즈니스 계층으로 요청을 위임하고 받은 결과를 응답하는 역할만 수행합니다.
비즈니스 계층은 애플리케이션이 제공하는 기능을 제공하고 세부 작업을 수행하는 도메인 객체를 통해 업무를 위임하는 역할을 수행합니다.
DDD(Domain Driven Design)기반의 아키첵쳐에서는 비즈니스 로직에 도메인이 포함되기도 하고, 별도의 도메인 계층을 두기도 합니다.
데이터 접근 계층은 데이터베이스에 접근하는 일련의 작업을 수행합니다.
Layered Architecture 기반 설계는 다음과 같은 특징을 지닙니다.
- 각 레이어는 가장 가까운 하위 레이어의 의존성을 주입받습니다.
- 각 레이어는 관심사에 따라 묶여 있으며, 다른 레이어의 역할을 침범하지 않습니다.
- 각 컴포넌트의 역할이 명확하므로 코드의 가독성과 기능 구현에 유리합니다.
- 코드의 확장성도 좋아집니다.
- 각 레이어가 독립적으로 작성되면 다른 레이어와의 의존성을 낮춰 단위 테스트에 용이합니다.
따라서 다음과 같은 모양을 띄게됩니다.
해당 사진은 일반적인 Layered Architecture를 스프링에 적용한 모습입니다.
특징은 비슷하긴하지만, 비즈니스 계층의 경우 때때로 서비스 계층이라고도 합니다. 해당 계층에서는 핵심 비즈니스 로직을 구현합니다.
추가적으로 트랙잭션 처리나 유효성 검사 등의 작업도 수행합니다.
또한, 데이터 접근 계층의 경우 상황에 따라 영속 계층이라고도 합니다.
2.4 디자인 패턴
디자인 패턴은 소프트웨어를 설계할 때 자주 발생하는 문제들을 해결하기 위해서 고안된 해결책입니다.
패턴이라는 단어는 애플리케이션 개발에서 발생하는 문제는 유사한 경우가 많고, 해결책도 동일하게 적용할 수 있다는 의미를 내포합니다.
하지만, 디자인 패턴이 모든 문제의 정답은 아니며, 상황에 맞는 최적 패턴을 결정해서 사용하는 것이 바람직합니다.
2.4.1 디자인 패턴의 종류
디자인 패턴을 구체화해서 정리한 대표적인 분류 방식으로 GoF 디자인 패턴이라는 것이 있습니다.
GoF란 'Gang of Four' 의 줄임말로, 디자인 패턴을 구체화하고 체계화해서 분류한 4명의 인물을 의미합니다.
GoF 디자인 패턴은 생성, 구조, 행위 패턴으로 총 3가지로 구분됩니다.
생성 패턴은 객체 생성에 사용되는 패턴으로 객체를 수정해도 호출부가 영향을 받지 않게하는 패턴입니다.
구조 패턴은 객체를 조합해서 더 큰 구조를 만드는 패턴입니다.
행위 패턴은 객체 간의 알고리즘이나 책임 분배에 관한 패턴입니다. 객체 하나로는 수행할 수 없는 작업을 여러 객체를 이용해 작업을 분배합니다. 결합도 최소화를 고려할 필요가 있습니다.
2.4.2 생성 패턴
추상 팩토리 : 구체적인 클래스를 지정하지 않고 상황에 맞는 객체를 생성하기 위한 인터페이스를 제공하는 패턴입니다.
빌더 : 객체의 생성과 표현을 분리해 객체를 생성하는 패턴입니다.
팩토리 메서드 : 객체의 생성을 서브클래스로 분리해서 위임하는 패턴입니다.
프로토타입 : 원본 객체를 복사해 객체를 생성하는 패턴입니다.
싱글톤 : 한 클래스마다 인스턴스를 하나만 생성해서 인스턴스가 하나임을 보장하고 어느 곳에서도 접근할 수 있게 제공하는 패턴입니다.
2.4.3 구조 패턴
어댑터 : 클래스의 인터페이스를 의도하는 인터페이스로 변환하는 패턴입니다.
브리지 : 추상화와 구현을 분리해서 각각 독립적으로 변형케 하는 패턴입니다.
컴포지트 : 여러 객체로 구성된 복합 객체와 단일 객체를 클라이언트에서 구별 없이 다루는 패턴입니다
데코레이터 : 객체의 결합을 통해 기능을 동적으로 유연하게 확장할 수 있게 하는 패턴입니다.
퍼사드 : 서브시스템의 인터페이스 집합들에 하나의 통합된 인터페이스를 제공하는 패턴입니다.
플라이웨이트 : 특정 클래스의 인스턴스 한 개를 가지고 여러 개의 '가상 인스턴스'를 제공할 때 사용하는 패턴입니다
프록시 : 특정 객체를 직접 참조하지 않고 해당 객체를 대행(프락시)하는 객체를 통해 접근하는 패턴입니다.
2.4.4 행위 패턴
책임 연쇄 : 요청 처리 객체를 집합으로 만들어 결합을 느슨하게 만드는 패턴입니다.
커맨드 : 실행될 기능을 캡슐화해서 주어진 여러 기능을 실행하도록 클래스를 설계하는 패턴입니다.
인터프리터 : 주어진 언어의 문법을 위한 표현 수단을 정의하고 해당 언어로 구성된 문장을 해석하는 패턴입니다.
이터레이터 : 내부 구조를 노출하지 않으면서 해당 객체의 집합 원소에 순차적으로 접근하는 방법을 제공하는 패턴입니다.
미디에이터 : 한 집합에 속한 객체들의 상호작용을 캡슐화하는 객체를 정의한 패턴입니다.
메멘토 : 객체의 상태 정보를 저장하고 필요에 따라 상태를 복원하는 패턴입니다.
옵저버 : 객체의 상태 변화를 관찰하는 관찰자들, 즉 옵저버 목록을 객체에 등록해 상태가 변할 때마다 메서드 등을 통해 객체가 직접 옵저버에게 통지하게 하는 디자인 패턴입니다.
스테이트: 상태에 따라 객체가 행동을 변경하게 하는 패턴입니다.
스트래티지: 행동을 클래스로 캡슐화해서 동적으로 행동을 바꿀 수 있게 하는 패턴입니다.
템플릿 메서드: 일정 작업을 처리하는 부분을 서브클래스로 캡슐화해서 전체 수행 구조는 바꾸지 않으면서 특정 단계만 변경해서 수행하는 패턴입니다.
비지터: 실제 로직을 가지고 있는 객체(visttor)가 로직을 적용할 객체(clement)를 방문하며 실행하는 패턴입니다.
2.5 REST API
REST API는 대중적으로 가장 많이 사용되는 애플리케이션 인터페이스입니다.
이 인터페이스를 통해 클라이언트가 서버에 접근하고 자원을 조작할 수 있습니다.
2.5.1 REST란?
REST란 Representational State Transfer의 약자로 WWW(World Wide Web)과 같은 분산 하이퍼미디어 시스템 아키텍쳐의 한 형식입니다. 주고받는 자원에 이름을 규정하고 URI에 명시해 HTTP 메서드를 통해 해당 자원의 상태를 주고받는 것을 의미합니다.
2.5.2 REST API란?
API는 Application Programming Interface로 애플리케이션에서 제공하는 인터페이스를 의미합니다.
API를 통해 서버 또는 프로그램 사이를 연결할 수 있습니다. 즉, REST API는 REST 아키텍쳐를 따르는 시스템/애플리케이션 인터페이스라고 할 수 있습니다.
2.5.3 REST의 특징
- Uniform Interface / 일관된 인터페이스
- REST 서버는 HTTP 표준 전송 규약을 따르기 때문에, 어떤 프로그래밍 언어로 작성되었느냐와 상관없이 플랫폼 및 기술에 종속되지 않고 타 언어, 프레임워크와 호환해 사용할 수 있다는 것을 의미합니다.
- Stateless / 무상태성
- REST는 무상태성이라는 특징을 가집니다. 무상태성이란 서버에 상태 정보를 따로 보관하거나 관리하지 않는다는 의미입니다. 서버는 클라이언트가 보낸 요청에 대해 세션이나 쿠키정보를 별도로 보관하지 않습니다. 때문에 한 클라이언트가 여러 요청을 보내든 여러 클라이언트가 각각 하나의 요청을 보내든 개별적으로 처리합니다. 이렇게 구성된 서비스는 서버가 불필요한 정보를 관리하지 않으므로 비즈니스 로직의 자유도가 높고 설계가 단순합니다.
- Cacheable / 캐시 가능성
- HTTP 캐싱 기능을 적용할 수 있습니다. 이 기능을 이용하기 위해서는 응답과 요청이 모두 캐싱 가능한지(Cacheable) 명시가 필요하며, 캐싱이 가능한 경우 클라이언트에서 캐시에 저장해두고 같은 요청에 대해서는 해당 데이터를 가져다 사용합니다. 이 기능을 사용하면 서버의 트랜잭션 부하가 줄어 효율적이며 사용자 입장에서 성능이 개선됩니다.
- Layered System / 레이어 시스템
- REST 서버는 네트워크 상의 여러 계층으로 구성될 수 있습니다. 그러나 서버의 복잡도와 관계없이 클라이언트는 서버와 연결되는 포인트만 알면 됩니다.
2.5.4 REST의 URL 설계 규칙
- URL의 마지막에는 "/"를 포함하지 않습니다.
- 언더바(_)는 사용하지 않습니다. 대신 하이픈(-)을 사용합니다.
- URL에는 행위(동사)가 아닌 결과(명사)를 포함합니다.
- URI는 소문자로 작성해야합니다.
- 파일의 확장자는 URI에 포함하지 않습니다.
'책' 카테고리의 다른 글
| [Book] 스프링 부트 핵심 가이드 Chap.4 (0) | 2024.06.25 |
|---|---|
| [Book] 스프링 부트 핵심 가이드 Chap.3 (0) | 2024.06.23 |
| [Book] 스프링 부트 핵심 가이드 Chap.1 (0) | 2024.06.23 |
| [데이터베이스 첫 걸음] 4주차 공부 내용 정리 (1) | 2023.10.17 |
| [데이터베이스 첫 걸음] 3주차 공부 내용 정리 (0) | 2023.10.17 |
