[Spring Boot] - 디자인 패턴, API, Pom파일, Swagger

본 게시물은 유튜브 채널 '어라운드 허브 스튜디오'의 스프링 부트 강의를 들으며 작성한 게시물입니다.
https://youtube.com/@around.hub.studio?si=wB1YEVq-ulj1r4Ao

어라운드 허브 스튜디오 - Around Hub Studio

---

3~11강 내용입니다.

1. 디자인 패턴

- 디자인 패턴이란 특정 문맥에서 공통적으로 발생하는 문제에 대해 쓰이는 재사용 가능한 해결책 : 설계도 같은 것. + 재사용 가능한 → 골격구조를 해결책으로 내는 것 == 디자인 패턴/ 목적별로 제시되는 패턴이 있음. → 직면한 상황에 따라서 어떻게 해야할지 사용하는 패턴 → 유연하게 수정하며 사용하면 됨.

- 인터페이스 → 패턴을 지키려고 쓰는 거다.

- GoF에서 제시한 23개의 패턴이 있음.

• 생성패턴 : 객체의 생성과 관련된 패턴
  *싱글톤: 한 클래스마다 인스턴스를 하나만 생성하여 어디서든 참조 (스프링부트의 싱글톤과는 약간 다름. 스프링에서 제공하는 싱글톤이 있음)
• 구조패턴 : 프로그램 내 자료 구조나 인터페이스 구조 등 프로그램 구조를 설계하는데 사용되는 패턴
  *어댑터: 클래스의 인터페이스를 어떤 클래스에서든 이용할 수 있도록 변환
  *브리지: 구현부에서 추상층을 분리하여 각자 독립적으로 변형하고 확장할 수 있도록 함
  *데코레이터: 주어진 상황에 따라 객체에 다른 객체를 덧붙임
  *파사드: 서브 시스템에 있는 인터페이스 집합에 대해 통합된 인터페이스 제공

• 행동패턴 : 반복적으로 사용되는 객체들의 커뮤니케이션을 패턴화 (객체 사이에 알고리즘 또는 책짐을 분배하는 방법에 대해 정의됨)
  *전략: 동일 계열의 알고리즘군을 정의하고 캡슐화하여 상호 교환이 가능하게 함
  *인터프리터: 특정 언어의 문법 표현을 정의

 

 

2. Rest APT

• 1. Application Programming Interface의 줄임말
  2. 응용프로그램에서 사용할 수 있도록 다른 응용 프로그램을 제어할 수 있게 만든 인터페이스를 뜻함
  3. API를 사용하면 내부 구현 로직을 알지 못해도 정의되어 있는 기능을 쉽게 사용할 수 있음API
     → 응용프로그램을 제어할 수 있도록 인터페이스를 정의해둔 명세서 → 이를 통해 어떤 방식으로 제어하고 사용하는지 알려주는 인터페이스
     ex. 마우스, 키보드, 터치패드 → 하나의 장치들, 우리는 이를 통해 어떤 기기로 정보를 전달함. : 하드웨어적인 설명
     *인터페이스: 어떤 장치간 정보를 교환하기 위한 수단이나 방법을 의미함
  1. Representational State Transfer의 줄임말
  2. 자원의 이름으로 구분하여 해당 자원의 상태를 교환하는 것을 의미 → 자원(데이터)의 상태
     - REST는 서버와 클라이언트의 통신 방식 중 하나 → 규약보단 아키텍처에 가까움
  3. HTTP URL를 통해 자원을 명시하고 HTTP Method를 통해 자원을 교환하는 것 → http통신을 함
     *HTTP Method: Create, Read, Update, Delete (crud) → 4개의 동작으로 자원을 컨트롤
  • 특징(규칙)
    1. 서버-클라이언트 구조
       → 서버와 클라이언트가 독립적으로 분리되어 있어야 함. → 자원이 공통적인 게 있으면 안 돼
    2. stateless
       → 요청 간에 클라이언트 정보가 서버에 저장되지 않음. 서버는 각각의 요청을 완전히 별개의 것으로 인식하고 처리
    3. cacheable
       → http프로토콜을 그대로 사용하기 때문에 http의 특징인 캐싱 기능을 적용. 대량의 요청을 효율적으로 처리하기 위해 캐시 사용
    4. 계층화
       → 클라이언트는 서버의 구성과 상관 없이 rest api 서버로 요청. 서버는 다중 계층으로 구성될 수 있음. (로드밸런싱, 보안요소, 캐시 등) → 여러대의 서버를 두고 다중계층/ 클라이언트는 계층과 상관없이 요청 했을 때 받아오기만 하면 됨
    5. code on demand(optional)
       → 요청을 받으면 서버에서 클라이언트로 코드 또는 스크립트(로직)을 전달하여 클라이언트 기능 확장
    6. 인터페이스 일관성(uniform interface)
       → 정보가 표준 형식으로 전송되기 위해 구성 요소 간 통합 인터페이스를 제공. http 프로토콜을 따르는 모든 플랫폼에서 사용 가능하게끔 설계.
  • rest api
    → rest 아키텍처의 조건을 준수하는 어플리케이션 프로그래밍 인터페이스를 뜻함. 최근 많은 api가 rest api로 제공되는 중.
    → 일반적으로 rest아키텍처를 구현하는 웹 서비스를 restful하다고 표현함
    특징 
    - rest기반으로 시스템을 분산하여 확장성과 재사용성을 높임
    - http표준을 따르고 있어 여러 프로그래밍 언어로 구현할 수 있음
  • rest api 설계규칙
    1. 웹 기반의 rest api를 설계할 경우 url를 통해 자원을 표현해야 함
    2. 자원에 대한 조작은 http method를 통해 표현해야 함
       → uri에 행위가 들어가면 안됨
    3. 메세지를 통한 리소스 조작
       → header를 통해 content-type을 지정하여 데이터를 전달. 대표적인 형식으로는 html, xml, json, text가 있음
       -> json을 가장 많이 사용함
    4. url에는 소문자를 사용
    5. resource의 이름이나 uri가 길어질 경우 하이픈을 통해 가독성을 높임
    6. 언더바는 사용 안 함
    7. 파일 확장자 표현 안 함
• pom.xml
  - 메이븐 프로젝트를 생성하면 루트 디렉토리에 생성되는 파일
  - 프로젝트 오브젝트 모델 정보를 담고 있음
  주요 설정 정보
  - 프로젝트 정보
  - 빌드 설정 정보
  - pom 연관 정보
• 프로젝트 기본 정보
  • <name> : 프로젝트명
  • <url> : 프로젝트 사이트 url
  • <description> : 프로젝트에 대한 간단한 설명
  • <organization> : 프로젝트를 관리하는 단체 설명
  • <groupId> : 프로젝트의 그룹 ID 설정
  • <artifactId> : 프로젝트 아티팩트 ID 설정
  • <version> : 프로젝트의 버전
  • <packaging> : 패키징 타입 설정-war : 웹 어플리케이션을 위한 패키징 방식
  • -jar : 자바 프로젝트 압축 파일
• 프로젝트 의존 설정
  • <dependencies> : 라이브러리 의존성 정보를 가지고 있는 디펜던시 태그를 묶은 태그
  • <dependency> : 각 라이브러리의 정보를 담는 태그
  • <groupId> : 의존성 라이브러리의 group ID
  • <artifactId> : 의존성 라이브러리의 아티팩트 ID
  • <version> : 의존성 라이브러리의 버전
  • <scope> : 해당 라이브러리의 이용 범위 지정
    
    

   

• <optional> : 다른 프로젝트에서 이 프로젝트를 의존성 설정을 할 경우 사용할지 결정
• 현재 시점에 설정되어 있는 라이브러리 설명 (pom파일에 설정되어 있는지 체크해보기)
  • spring boot starter parent
    1. 프로젝트에서 사용하는 다양한 라이브러리 간의 버전 충돌 문제가 발생할 수 있는 것을 방지.
    2. 의존성 조합간 충돌 문제가 없는 검증된 버전 정보 조합을 제공
  • spring boot starter web
    1. spring MVC를 사용한 rest 서비스를 개발하는데 사용 → 꾸러미 제공
  • spring boot starter test
    - 1 JUnit, Hamcrest, Mockito를 포함한 스프링 어플리케이션의 테스트 기능을 제공

*lombok: 어노테이션으로 직접 메소드를 만들지 않아도 대체해줌

 

 

• mvc
  - 디자인 패턴 중 하나
  - model, view, controller의 줄임말로 어플리케이션을 구성할 때 그 구성요소를 세가지의 역할로 구분한 패턴을 의미함
  - 사용자 인터페이스로부터 비즈니스 로직을 분리하여 서로 영향 없이 쉽게 고칠 수 있는 설계가 가능함.

 

 

 

 

 

 

 

 

 

 

 

- 컨트롤러: 모델과 뷰 사이 브릿지 역할. 앱의 사용자로부터 입력에 대한 응답으로 모델 및 뷰를 업데이트 하는 로직을 포함. 컨트롤러로 들어온 요청은 어떻게 처리할지 결정하여 모델로 요청을 전달함
- 모델: 데이터를 처리하는 영역. 데이터베이스와 연동을 위한 DAO와 데이터의 구조를 표현하는 DO로 구성됨 → 무조건적은 아님. 요소는 바뀔 수 있다
- 뷰: 데이터를 보여주는 화면 자체의 영역을 뜻함. 사용자 인터페이스 요소들이 여기에 포함되며, 데이터를 각 요소에 배치함. 뷰에서는 별도의 데이터를 보관하지 않음.

• 컨트롤러 만들기
  1. @RestController
  • 스프링 프레임워크 4버전부터 사용가능한 어노테이션
  • @Controller에 @ResponseBody가 결합된 어노테이션컨트롤러 클래스 하위 메소드에 @ResponseBody 어노테이션을 붙이지 않아도 문자열과 JSON 등을 전송할 수 있음.
  • view를 거치지 않고 http ResponseBody에 직접 return값을 담아 보내게 됨

    2. @RequestMapping

• mvc의 핸들러 매핑을 위해서 defaultAnnotationHandlerMapping을 사용
• defaultAnnotationHandlerMapping 매핑 정보로 @RequestMapping 어노테이션을 활용
• 클래스와 메소드의 RequestMapping을 통해 URL을 매핑하여 경로를 설정하여 해당 메소드에서 처리
• value: url 설정
• method: GET, POST, DELETE, PUT, PATCH 등
  → 메소드 지정방식보단 간단하게 어노테이션 사용 가능
  → @GetMapping
  → @DeleteMapping
  → @PatchMapping
  → @PutMapping
  → @PostMapping

 

 

• GET API 만드는 방식
  1. @RequestMapping
  → 너무 고전적이라 이젠 사용 안 함
  → value, method로 정의해서 api를 개발하는 방식
  2. @GetMapping
  → 별도의 파라미터 없이 겟 api를 호출하는 경우 사용되는 방법
  3. @PathVariable
  → get형식의 요청에서 파라미터를 전달하기 위해 url에 값을 담아 요청하는 방법
  → 아래 방식은 @GetMapping에서 사용된 {변수}의 이름과 메소드의 매개변수와 일치시켜야 함
  4. @RequestParam
  → ‘?’를 기준으로 우측에 {키}={값}의 형태로 전달되며, 복수 형태로 전달할 경우 &를 사용함
  → get형식의 요청에서 쿼리 문자열을 전달하기 위해 사용되는 방법
  5. DTO 사용
  - key, value가 정해져있지만, 받아야할 파라미터가 많을 경우 DTO객체를 사용한 방식

 

• POST API 만들기
  - POST API: 리소스를 추가하기 위해 사용되는 api
  - @PostMapping: POST API를 제작하기 위해 사용되는 어노테이션
      @RequestMapping + POST method의 조합
  → 일반적으로 추가하고자 하는 Resource를 http body에 추가하여 서버에 요청
  → 그렇기 때문에 @RequestBody를 이용하여 body에 담겨있는 값을 받아야함
  ex. 

//http://localhost:8080/api/v1/paost-api/member
@PostMapping(value="/member") //url설정
public String postMember(@RequestBody Map<String, Object> postData) {
	StringBuilder sb = new StringBuilder(); //RequestBody에 map이라는 객체를 만들어서 값을 받음

//StringBuilder로 들어온 객체에 뭐가 있는지 하나씩 까보는 작업 👇
postData.entrySet().forEach(map -> {
	sb.append(map.getKey() + " : "+map.getValue()+"\n");
});
return sb.toString(); //toString으로 return
}

   - DTO 사용하는 방식
      -key, value가 정해져있지만, 받아야할 파라미터가 많을 경우 DTO 객체를 사용한 방식

      -@RequestBody 안 붙이면 null 뜰 수도… 꼭 붙이기

 

 

 

• Swagger
  -협업을 위한 라이브러리
  -서버로 요청되는 API 리스트를 html 화면으로 문서화하여 테스트 할 수 있는 라이브러리
  -restcontroller어노테이션을 읽어 api 분석해서 html문서를 작성함 (다른 언어도 가능)
  -사용하는 이유: rest api의 스펙을 문서화 하는 것은 매우 중요한데 api를 변경할 때마다 자동으로 변경해줌
  -2.9.2 버전으로 할 것
  -@Configuration : 어노테이션 기반의 환경 구성을 돕는 어노테이션/ IoC Container에게 해당 클래스를 Bean 구성 Class임을 알려줌
  -@Bean: 개발자가 직접 제어가 불가능한 외부 라이브러리 등을 Bean으로 만들 경우에 사용