Spring Boot 개발에 앞서 알면 좋은 기본 지식

서버간 통신

---

어떤 포털 사이트를 하나의 서비스 단위로 개발한다고 한다고 가정하자, 블로그, 게시판, 카페, 메일 등등의 기능들을 하나의 애플리케이션에 통합합니다. 서비스를 이렇게 구성하면 유지보수할 때마다 하나의 서비스만 존재하므로 서비스를 닫아놔야 할 것입니다. 또한 규모가 점점 커지면 시간도 오래걸립니다. 

 

이를 해결하기 위해서 마이크로 아키텍쳐(Microservice Architecture)가 있습니다. 마이크로 아키텍쳐는 단어 그대로 서비스 규모를 작게 나누어 구성한 아키텍쳐 입니다. 위의 그림처럼 두 개발 방식을 비교할 수 있습니다. 우측 그림처럼 독립적인 애플리케이션들을 개발하게 되면, 각 서비스 간에 통신을 해야하는 경우가 생깁니다. 예를들어 [로그인 > 블로그 사용] 같은 동작이 있습니다. 이런 상황의 통신을 '서버 간 통신' 이라고 합니다.  

 

 

 

 

 

 

 

 

 

스프링 부트의 동작방식

---

스프링 부트에서는 'start-boot-starter-web' 모듈을 사용해서 기본적으로 톰캣을 이용하는 스프링 MVC 구조를 기반으로 동작합니다. 위의 그림은 일반적인 웹 요청이 들어올 때의 스프링 부트의 동작 구조입니다. 

 

1). Request(요청)가 서블릿으로 들어옵니다. 서블릿(Servlet)은 클라이언트의 요청을 처리하고 결과를 반환한느 자바  웹 프로그래밍 기술입니다. 일반적으로 서블릿은 서블릿 컨테이너(Servlet Container)에서 관리합니다. 스프링에서 서블릿 컨테이너는 Dispatcher Servlet이 역할을 수행합니다. 

**서블릿 컨테이너
    서블릿 객체를 생성,초기화,호출,종료  등의 생명주기를 관리합니다. 
    서블릿 객체는 싱글톤 패턴으로 관리됩니다.
    멀티 스레딩을 지원합니다.

2). Dispatcher Servlet으로 요청(Request)이 들어오면 핸들러매핑(Handler Mapping)을 통해서 요청 URL에 매핑된 핸들러를 탐색합니다. 여기서 핸들러는 컨트롤러(Controller)를 의미합니다. 이후 컨트롤러를 호출합니다.

**핸들러 매핑(Handler Mapping) 
	요청 정보를 기준으로 어떤 컨트롤러를 사용할지 선정하는 인터페이스입니다.

 

3). 핸들러 어댑터에 컨트롤러의 응답이 돌아오면 ModelAndView를 응답으로 반환받습니다.

 

4).  뷰 형식으로 리턴하는 컨트롤러를 사용할 때는 뷰 리졸버(View Resolver)를 통해 뷰(View)를 받아서 리턴합니다. 

 

 

 

 

 

 

 

 

 

 

레이어드 아키텍쳐

---

레이어드 아키텍쳐(Layered Architecture)란 애플리케이션의 컴포넌트를 유사 관심사를 기준으로 레이어로 묶어 수평적으로 구성한 구조를 의미합니다. 레이어드 아키텍쳐는 위와같이 3-4계층의 구성을 의미합니다.

프레젠테이션 계층(Presentation Layer) - 애플리케이션의 최상단으로, 클라이언트의 요청을 해석하고 응답하는 역할입니다. 비즈니스 계층(Bussiness Layer) - 애플리케이션이 제공하는 기능을 정의하고 세부 작업을 수행하는 도메인 객체를 통해 업무를 위임하는 역할을 수행합니다. 데이터접근 계층(Persistence , Database Layser) - 데이터베이스에 접근하는 일련의 작업을 수행합니다.

스프링에서 VIew, Controller가 프레젠테이션 계층에 해당하며, Model은 비즈니스와 데이터 접근 계층의 영역으로 구분할 수 있습니다. 데이터 접근 계층에는 DAO(Spring Data JPA에서는 Repository)를 배치해서 도메인을 관리합니다.

 

 

 

 

 

 

 

 

 

 

REST API

---

REST API는 대중적으로 가장 많이 사용되는 애플리케이션 인터페이스 입니다. 이 인터페이스를 통해서 클라이언트는 서버에 접근하고 자원을 조작할 수 있습니다. 

 

 

 

REST?

---

REST는 'Representational State Transfer'의 약자로 월드 와이드 웹 ('world' , 'wide' , 'web')과 같은 분산 하이퍼미디어 시스템 아키텍쳐의 한 형식입니다. 주고받는 자원(Resource)에 이름을 규정하고 URL에 명시해서 HTTP 메서드(GET, POST, PUT, DELETE)를 통해서 자원의 상태를 주고받는 것을 의미합니다. 

 

 

 

REST API?

---

REST API는 REST 아키텍처 스타일을 따르는 API로, HTTP 프로토콜을 기반으로 클라이언트와 서버 간의 통신을 수행합니다. REST API는 유니폼 인터페이스, 무상태성, 캐시 가능성, 레이어 시스템, 클라이언트-서버 아키텍쳐 등의 특성을 가집니다.

 

 

 

 

 

REST의 URL규칙

---

REST API의 URL(Uniform Resource Locator) 설계에는 몇 가지 일반적인 규칙과 권장 사항이 있습니다.  REST API의 URL 설계에 대한 몇 가지 규칙입니다.

 

• 명사를 사용: URL은 주로 자원(명사)을 나타내어야 합니다. 동사나 동작을 나타내는 단어보다는 자원의 이름이 들어가는 것이 좋습니다. 예를 들어, /users는 사용자 자원을 나타내는 URL입니다.
  
  
• 복수형 사용: 자원을 나타내는 URL은 일반적으로 복수형을 사용합니다. 여러 개의 자원을 나타내기 때문에 복수형이 자연스러운 표현입니다. 예를 들어, /users는 여러 개의 사용자를 나타내는 URL입니다.
  
  
• 계층 구조 활용: URL은 계층 구조를 사용하여 관련된 자원을 표현할 수 있습니다. 예를 들어, /users/{userId}/posts는 특정 사용자의 게시물을 나타내는 URL입니다. 여기서 {userId}는 경로 매개변수로, 실제 사용자 ID 값으로 대체됩니다.
  
  
• 동사를 피하기: URL에 동사를 사용하는 것은 좋지 않습니다. 대신 HTTP 메서드를 사용하여 동작을 나타냅니다. 예를 들어, POST /users는 사용자를 생성하는 동작을 나타냅니다.
  
  
• 필터링과 정렬: 필터링과 정렬을 위한 매개변수는 URL의 쿼리 문자열(Query String)에 포함될 수 있습니다. 예를 들어, /users?status=active는 활성화된 사용자를 필터링하는 URL입니다.
  
  
• 하이픈 대신 언더스코어 사용: URL에서 단어를 구분할 때는 하이픈 대신 언더스코어를 사용하는 것이 일반적입니다. 예를 들어, /user-profiles는 사용자 프로필을 나타내는 URL입니다.
  
  
• 일관성 유지: URL은 일관성을 유지해야 합니다. 유사한 자원은 유사한 URL 패턴을 가지도록 설계하는 것이 좋습니다. 예를 들어, /users/{userId}/posts와 /users/{userId}/comments는 사용자의 게시물과 댓글을 나타내는 URL로 일관성을 유지합니다.