책 링크
매주 스프링 부트 핵심 가이드 를 읽으며 이전에 궁금했거나, 새롭게 알게 된 내용들을 정리할 예정이다.
레이어드 아키택쳐
레이어드 아키택쳐(Layered Architecture)란, 어플리케이션의 컴포넌트를 유사 관심사를 기준으로 레이어로 묶어 수평적으로 구성한 구조를 의미한다. 일반적으로 프레젠테이션 계층, 비즈니스 계층, 데이터 접근 계층의 3계층으로 이루어져 있으며, 이를 스프링과 스프링 MVC(Model-View-Controller)에 적용하면 View와 Controller는 프레젠테이션 계층, Model은 비즈니스 와 데이터 접근 계층으로 구분할 수 있다. 다만 Model을 세분화하여 비즈니스 계층에 서비스, 데이터 접근 계층에 DAO를 배치하여 도메인을 관리한다. 자세하게 설명하면 다음과 같다.
프레젠테이션 계층
- 유저 인터페이스(UI, User Interface) 계층이라고도 한다.
- 클라이언트와 가장 가깝게 맞닿아 있다.
- 클라이언트로부터 데이터와 요청을 받고 API의 결과를 응답으로 전달한다.
비즈니스 계층
- 서비스(Service) 계층이라고도 한다.
- 핵심 비즈니스 로직을 구현한다.
- 트랜잭션이나 유효성 검사 등의 작업도 수행한다.
데이터 접근 계층
- 영속(Persistence) 계층이라고도 한다.
- 데이터베이스에 접근하는 작업을 수행한다.
- 일반적으로 DAO(Data Access Object, 데이터 접근 객체)를 이용한다고 표현하지만, Spring Data JPA(Java Persistence API)에서는 리포지토리(Repository)가 DAO의 역할을 수행한다.
REST API
REST API, RESTful하게, 이런 말을 많이 들어는 봤는데 이에 대해 자세하게 알지는 못했었다. 이번 기회에 확실하게 알아보고 정리하려 한다.
REST란?
Representional State Transfer의 약자로, WWW(월드 와이드 웹)과 같은 시스템 아키택쳐의 형식이다. 같은 주고받는 자원에 이름을 규정하고 URI에 명시해 HTTP 메소드(GET, POST, PUT, DELETE)를 통해 해당 자원의 상태를 주고받는 것을 의미한다.
REST API란?
REST 아키택쳐를 따르는 API라고 할 수 있다. 또한 이를 따르는 API를 RESTful하다고 표현한다.
그렇다면 REST의 특징은?
-
유니폼 인터페이스 - 플랫폼과 기술에 종속되지 않고 일관된 인터페이스를 따른다.
-
무상태성(Stateless) - 서버는 클라이언트가 보낸 요청에 대한 정보를 별도 보관하거나 관리하지 않는다. 그러므로 한 클라이언트가 여러 요청을 보내든 여러 클라이언트가 하나의 요청을 보내든 모두 개별적으로 처리하며, 서버가 불필요한 정보를 관리하지 않기 때문에 비즈니스 로직의 자유도가 높고 설계가 둔산하다.
-
캐시 가능성 - HTTP 표준을 그대로 사용하므로 캐싱을 적용할 수 있다. 별도의 명시가 필요하며 같은 요청의 경우에 클라이언트가 캐시에 저장된 데이터를 불러와 다시 사용한다. 서버의 부하도 줄이고 사용자가 느끼는 성능도 개선된다.
-
레이어 시스템 - 네트워크 상의 여러 계층으로 구성될 수 있으나, 서버가 복잡한 것과 관계없이 클라이언트는 서버와 연결되는 포인트만 알면 된다.
-
클라이언트-서버 아키택쳐 - 클라이언트와 서버를 서로 분리하여 설계해 서로의 의존성을 낮춘다.
REST한 URI 설계 규칙
URI는 Uniform Resource Identifier 의 줄임말이며, 통합 자원 식별자라는 의미를 가지고 있다. 우리에게 익숙한 URL은 Locator, 즉 주소를 의미하며 URI에 포함된 개념이다. (URI가 더 포괄적인 개념)
REST API를 설계하는 데에 다음과 같은 규칙들이 있다고 한다.
- URL의 마지막에는
/을 포함하지 않는다. - 언더바
_대신 하이픈-을 이용한다. - URL에는 행위(동사) 가 아닌 결과(명사) 를 포함한다.
- 소문자로 작성해야 한다.
- 파일의 확장자는 포함하지 않는다.
마무리하며
책을 읽고 공부하면서 바로 와닿은 부분이 하나 있었다. 바로 REST API를 설계할 때의 규칙 중 세번째 규칙이다. URL에 행위가 아닌 결과를 포함한다는 부분이었는데, 스프링을 이용한 API 개발 강의를 들을 때 똑같은 정보(info 라고 가정하자)를 각각 저장, 조회, 삭제, 수정하는 API의 이름을 짓는다고 생각해보면,
/save-info, /get-info, /delete-info, /modify-info이런 식으로 하지 않고
GET /info, POST /info, DELETE /info, PUT /info로 HTTP 메서드만 구분하여 개발하는 이유가 규칙 중 하나였다는 것을 알게 되었다.
아직 책을 많이 읽지는 못했지만, 다 읽고 나면 분명 스프링에 대한 이해를 더 발전시킬 수 있을 것을 기대한다.
