Post

TIL- Spring 이해(1)

TIL- Spring 이해(1)

2024-05-13

Spring 입문주차

gradle이란 ?


  • 빌드 자동화 시스템, 빌드 : 우리가 작성한 소스 코드를 실행 가능한 결과물로 만드는 일련의 과정.

  • gradle을 사용하면 간편하게 자바의 소스파일을 실행가능한 jar 파일로 만들어줌

  • build.gradle

    • groovy 언어로 작성

    • 라이브러리 관리

    • dependencies 안에 작성하면 gradle이 해당 라이브러리들을 Maven 레포지토리라는 외부 저장소에서 자동으로 다운로드함.

    • Maven repogitory : 라이브러리들을 모아온 저장소

    • 라이브러리를 추가해주면 코끼리 모양의 표시 생성, 해당 표시를 클릭하면 추가된 라이브러리를 다운로드 함!
    • External Libraries에서 Gradle이 다운로드 해온 라이브러리들을 확인할 수 있음

Server


  • 네트워크를 왜 알아야될까?
    • 사용자가 요청을 했을 때 해당 요청에 대한 응답을 수행하는 프로그램인 서버를 개발하게 될 것.

    • 그렇다면 사용자의 요청에서 시작하여 우리가 만든 서버에 도착하고 다시 사용자에게까지 되돌아가는 흐름을 잘 파악한다면 서버 개발에 큰 도움이 될 것!

  • IP 주소 : 사용자의 요청이 해당 서버에 정확하게 도달할 수 있게 제공되는 정보
 택배네트워크

|–|–|–|

주소(IP)서울시 **구 **로192.168.*.
받는 사람(포트)nayoung8080
  • 웹 서버의 기본 동작 원리
      1. 브라우저를 통해 HTTP Request로 웹 사이트를 웹 서버에 요청함
      1. 이후 웹 서버는 요청을 승인하고 HTTP Response를 통해 웹사이트 데이터를 브라우저에 전송함
      1. 브라우저는 서버에서 받아온 데이터를 이용해 웹사이트를 브라우저에 그려내는 일을 함.
      • 기본적으로 브라우저가 웹서버에 요청할 때 항상 GET method로 요청함.
  • API : 다른 소프트웨어 시스템과 통신을 하기 위해 따라야하는 하나의 규칙을 정의한 것

  • 인터페이스는 서로 다른 두 개의 시스템, 장치 사이에서 정보나 신호를 주고받는 경우의 접점이나 경계면을 의미함. 즉, 사용자가 기기를 쉽게 동작시키는데 도움을 주는 시스템을 의미함.

  • Restful API : API 작동방식에 대한 조건을 부가하는 SW 아키텍처. Rest 아키텍처 스타일을 따르는 API를 Rest API라고 부르고 Rest 아키텍처를 구현하는 웹 서비스를 Restful 웹 서비스라고 부름.

    • 쉽게 말해 API가 적절하게 HTTP를 준수하면서 잘 설계되어있으면 Restful하게 설계되어있다고 생각.

    • API의 리소스 식별자를 중복 없이 고유하게 잘 만들고 해당 API에 적절하게 HTTP 메서드를 사용했다면 RESTful하게 설계했다고 볼 수 있음.

  • Web server : 브라우저에서 URL을 입력하여 어떠한 페이지를 요청했을 때 HTTP의 요청을 받아들여 HTML 문서와 같은 정적인 콘텐츠를 사용자에게 전달해주는 역할을 하는 것

  • 웹 서버 역할

    • 브라우저에서 URL을 입력하여 어떠한 페이지를 요청했을 때 HTTP의 요청을 받아들여 HTML 문서와 같은 정적인 콘텐츠를 사용자에게 전달해주는 역할을 하는 것.

    • 정적인 콘텐츠, 이미 완성 되어있는 HTML과 같은 문서를 브라우저로 전달

    • 브라우저로부터 ‘로그인하여 MyPage를 요청’과 같은 동적인 요청이 들어왔을 때 웹 서버 자체적으로 처리하기 어렵기 때문에 해당 요청을 WAS로 전달

    • 종류로 Apache, Nginx 등

  • WAS

    • 웹 서버와 똑같이 HTTP 기반으로 동작

    • 웹 서버와 함께 사용하면 효과적

    • 종류로 Tomcat, JBoss 등

  • Apache Tomcat

    • Tomcat은 동적인 처리를 할 수 있는 웹 서버를 만들기 위한 웹 컨테이너

    • Apache와 Tomcat이 합쳐진 형태로 정적인 데이터 처리와 동적인 데이터 처리를 효율적으로 해결.

  • SpringBoot와 Spring 차이

    • Srping 프레임 워크는 아주 오래되고 강력한 프레임 워크, Spring 프레임워크는 AOP, IoC/DI 등과 같은 아주 강력한 핵심 기능들을 가지고 있음.

1

  • 하지만 이런 핵심 기능들을 사용하기 위해서는 너무 많은 xml 설정들이 필요했음. 이런 불편한 점을 개선하기 위해 2014년 SpringBoot가 등장

  • SpringBoot는 기존의 xml 설정 대신 Java 애너테이션 기반의 설정을 적극적으로 사용하고 있기 때문에 무겁고 작성하기 힘들던 xml 대신에 애너테이션을 사용하여 아주 간편하게 설정할 수 있음.

    • 기본적으로 개발에 필요한 설정 정보들을 일반적으로 많이 사용하는 설정 값을 default로 하여 자동으로 설정
  • 또한 외부 라이브러리나 하위 프레임워크들의 의존성 관리가 매우 쉬워졌음.

1

  • 기존에는 외부 라이브러리와 프레임워크를 사용하기 위해서 각각의 버전들의 호환성을 직접 확인해가면서 의존성들을 설정해야 했지만 SpringBoot에서는 spring-boot-starter-web 처럼 필요한 외부 라이브러리들과 프레임워크들을 의존성에 맞게 starter로 묶어서 제공.

    • 따라서 이전처럼 각각의 버전 호환성을 직접 확인할 필요가 없어졌음.
  • SprinbBoot의 가장 강력한 점 : 내장 Apache Tomcat

  • Spring 프레임워크에서는 서버를 실행시키기 위해 Apache Tomcat을 직접 다운로드 받고 설정하고 프로젝트에 삽입했어야 함.

  • 이런 불편한 점을 해결하기 위해 SpringBoot에서는 기본적으로 starter-web dependency 를 설정하면 자동으로 내장형 Apche Tomecat을 제공해 줌.

  • Apache Tomcat이 내장되어있기 때문에 개발자가 따로 다운로드 받고 설정하고 삽입할 필요 없이 바로 사용 가능

  • Postman

    • API 개발을 빠르고 쉽게 구현할 수 있도록 도와주는 소프트웨어 플랫폼

    • API는 하나의 “약속”이라고 하고 우리가 API 즉, 약속에 맞춰서 HTTP 요청을 서버에 보내고 응답을 확인해봐야 우리가 만든 서버가 제대로 동작하는지 확인할 수 있음. 이러한 확인 작업을 간편하게 할 수 있도록 도와주는 플랫폼

    • API 테이블은 API들을 한눈에 확인하고 협업하는 개발자들과 소통하기 위해 작성하는 일종의 표

HTTP


  • 데이터를 주고 받는 양식을 정의한 “통신 규약”중 하나

  • 매우 범용적인 양식을 가지고 있어 전 세계에서 제일 널리 쓰이는 통신 규약

  • 여기서 말하는 통신 규약이란, 컴퓨터끼리 데이터를 주고 받을 때 정해둔 약속

    • 예를들어 한국어로 말을 걸면 한국어를 바로 이해할 수 있지만 갑자기 중국어나 불어로 말하면 알아듣지 못할 것. 마찬가지로 컴퓨터끼리 데이터를 주고 받을 때 정해진 규칙 없이 매번 요청하는 방식이 다르다면 소통에 큰 문제가 발생할 것
  • 따라서 현재 이용되는 대부분의 웹 서버가 HTTP를 기반으로 정해준 규칙에 맞게 데이터를 주고 받음.

  • 또한, 모든 브라우저는 HTTP 프로토콜을 기본으로 지원하기 때문에 우리는 매일 HTTP를 이용하는 셈

  • 어떻게 HTTP로 데이터를 주고받을까?

    • HTTP에서는 언제나 Request, Response라는 개념이 존재

      1. 브라우저는 서버에게 자신이 원하는 페이지(URL 등의 정보)를 요구(Request)
      1. 서버는 브라우저가 원하는 페이지가 있는지 확인하고, 있다면 해당 페이지에 대한 데이터를 실어 응답(Response). 없다면 없는 페이지에 대한 데이터를 반환
      1. 브라우저는 서버에게 전달 받은 데이터를 기반으로 브라우저에 그려줌.
  • Headers

    • General : 브라우저에서 서버로 보낸 Request 데이터

    • General

    1

    • Status Code 200은 ‘요청이 성공했다’라는 뜻

    • HTTP 상태 코드(Status Code)를 통해 브라우저와 서버간의 요청, 응답 과정에서 발생할 수 있는 상황들을 표현

    • HTTP 상태 코드는 3자리 숫자로 이루어져 있음

    • 첫 번째 자리 숫자는 상태 코드의 분류를 나타내는 용도로 사용되며, 나머지 두 자리는 세부적인 정보를 나타냄

    • 1xx (Informational)

      • 1xx 상태 코드는 요청이 수신 되었으며 처리가 계속되고 있음을 나타냄.

      • 주로 웹 브라우저와 같은 클라이언트가 서버와의 연결 상태를 확인하기 위해 사용

    • 2xx (Successful)

      • 2xx 상태 코드는 클라이언트의 요청이 성공적으로 처리 되었음을 나타냄.

      • 가장 많이 사용되는 상태 코드는 200

      • 이는 요청이 성공적으로 처리 되었으며 클라이언트가 요청한 데이터가 서버에서 제공됨을 의미

      • 3xx (Redirection)

        • 3xx 상태 코드는 클라이언트가 추가적인 조치를 취해야 함을 나타냅니다.

        • 이 상태 코드는 주로 페이지 이동, 리다이렉션 등에 사용됩니다.

      • 4xx (Client Error)

        • 4xx 상태 코드는 클라이언트에 오류가 있음을 나타냄.

        • 이 상태 코드는 주로 클라이언트의 잘못된 요청, 인증 오류 등에 사용

        • 가장 많이 사용되는 상태 코드는 404. 이는 클라이언트가 요청한 페이지나 리소스를 서버에서 찾을 수 없음을 의미함

      • 5xx (Server Error)

        • 5xx 상태 코드는 서버에 오류가 발생했음을 나타냄.

        • 이 상태 코드는 주로 서버의 오류, 서버 과부하 등에 사용

        • 가장 많이 사용되는 상태 코드는 500. 이는 서버 내부 오류가 발생함을 의미

  • Request Headers

    • 브라우저에서 서버로 보낸 Request 데이터
  • Response Headers

    • 서버가 웹 페이지 데이터와 함께 보낸 추가 데이터
  • HTTP 구성요소
    • GET : 어떤 리소스를 얻을 때 사용. 브라우저의 주소창에 URL을 입력하면 GET 메서드를 사용해서 서버에 요청을 보냄
    • POST: 웹 서버에 데이터를 게시할 때 사용하는게 일반적(ex. 회원가입, 게시글 작성, 댓글 작성)
    • 그외 DELETE 등의 여러 요청 방식이 존재
  • Header (추가 데이터, 메타 데이터)

    • 브라우저가 어떤 페이지를 원하는지
    • 요청 받은 페이지를 찾았는지

    • 요청 받은 데이터를 성공적으로 찾았는지

    • 어떤 형식으로 데이터를 보낼지
1
2
3
GET naver.com HTTP/1.1

  • 이러한 사례 외에도 아주 다양한 의사 표현을 위한 데이터를 모두 Header 필드에 넣고 주고 받습니다. 위에서 설명 된 메서드도 사실은 헤더에 포함되어 서버로 보내짐.

  • Payload (데이터, 실제 데이터)

    • 서버가 응답을 보낼 때는 항상 payload를 보낼 수 있음

    • 클라이언트(브라우저)가 요청을 할 때에도 Payload를 보낼 수 있음

    • "GET method를 제외하곤 모두 Payload를 보낼 수 있다" 는게 HTTP에서의 약속

테스트 코드


  • 버그

    • 소스코드나 설계과정에서의 오류 때문에 발생
  • 소프트웨어가 예상한대로 결과를 내는지 모든 상황을 체크해보기

    • 하지만 버그는 사용자에게 생각보다 큰 불편이나, 회사에 큰 악영향을 줌. 일부 기능이 동작하지 않는데 그 일부 기능이 이커머스 사이트의 ‘주문’이라면? 일부 기능이 의도와 다르게 동작하는데 그 기능이 이커머스 사이트의 ‘주문’이고, 10만원 결제건이 100만원이 결제되었다면? 피크시간대에 회사의 서비스가 다운된다면? 위와같은 일이 자주 일어나서 사용자들이 “이 사이트 이렇게 버그 많은데, 내 개인정보는 잘 보관하겠지?” 와 같은 의문을 가진다면? -> 버그의 안 좋은 점
  • 개발 코드 배포 전, 버그를 (최대한 많이) 찾아내는 법 -> 테스트

  • 블랙박스 테스팅

    • SW 내부 구조나 동작원리를 모르는 블랙박스와 같은 상태에서, 즉 웹 서비스의 사용자 입장에서 동작을 검사하는 방법

    • 장점

      • 누구나 테스트가 가능합니다 - 개발자부터 디자이너, 베타 테스터 혹은 사장님까지!
    • 단점

      • 기능이 증가될 수록 테스트의 범위가 증가

      • 시간이 갈수록 테스트하는 사람이 계속 늘어나야함

    • 테스트 하는 사람에 따라 테스트 퀄리티가 다를 수 있습니다. → QA 직군이 있는 이유

  • 개발자 테스트

    • 개발자가 직접 “본인이 작성한 코드”를 검증하기 위해 “테스트 코드”를 작성

    • 장점

      • 빠르고 정확한 테스트가 가능 (예상 동작 VS 실제 동작)

      • 테스트 자동화가 가능

      • 배포 절차 시 테스트 코드가 수행되어 동작 검증

      • 리팩토링이나 기능 추가를 할 때 더욱 편리

    • 단점

      • 개발 시간이 오래 걸림

      • 테스트 코드를 유지보수하는 비용

    • Spring에서는 테스트 코드를 작성을 잘 할 수 있는 환경을 제공

  • JUnit : 자바 프로그래밍 언어 용 단위 테스트 프레임워크

1

  • build.gradle 파일을 열어보면 JUnit 사용을 위한 환경설정이 이미 되어있음

  • Java는 반드시 main() 메서드로 시작해 main() 메서드로 끝난다고 배웠지만 JUnit은 테스트 실행 환경을 가지고 있기 때문에 따로 main() 메서드를 실행하거나 서버를 실행시키지 않아도 각각의 메서드 혹은 기능별로 테스트 코드를 작성하여 실행시킬 수 있음

Lombok과 application.properties


  • Lombok(이하 롬복)은 자바 프로젝트를 진행하는데 거의 필수적으로 필요한 메서드/생성자 등을 자동 생성해줌으로써 코드를 절약할 수 있도록 도와주는 라이브러리
1
2
3
4
5
@Getter
public class Memo {
    private String username;
    private String contents;
}
  • 클래스 위에 롬복 @Getter를 추가한 후 컴파일된 코드를 확인해보면 이처럼 직접 작성하지 않은 getUsername(), getContents() 메서드가 자동으로 추가되어있음을 확인할 수 있습니다.

  • 메서드마다 Getter, Setter를 만들면 너무나 많은 메서드가 만들어질 것임. 이를 Lombok을 사용하여 해결

  • @AllArgsConstructor, NoArgsConstructor

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
@NoArgsConstructor

@AllArgsConstructor

public  class  Memo {
	private  String  username;
	private  String  contents;

}

...

public  Memo() {
}

public  Memo(String username, String contents) {

	this.username = username;
	this.contents = contents;

}
  • 기본 생성자와 모든 필드를 파라미터로 가진 오버로딩된 생성자를 만들어 줌.

  • @RequiredArgsConstructor

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
@RequiredArgsConstructor

public  class  Memo {
	private  final  Calculator  calculator;
	private  final  String  username;
	private  String  contents;
}
...

  

public  Memo(Calculator calculator, String username) {

	this.calculator = calculator;
	this.username = username;

}

  • final 제어자가 붙은 필드를 파라미터로 가진 오버로딩된 생성자를 만들어 줌.

  • application.properties

    • application.properties는 Spring과 관련된 설정을 할 때 사용되는 파일

    • Spring과 SpringBoot의 차이에 대해 학습할 때 SpringBoot를 사용하면 개발에 필요한 설정 정보들이 자동으로 설정된다고 배웠음.

    • 이 파일을 사용하면 자동으로 설정되고 있는 설정 값을 쉽게 수정할 수 있음.

    • 뿐만아니라 DB 연결 시 DB의 정보를 제공해야하는데 이러한 경우에도 이 파일을 이용하여 쉽게 값을 전달할 수 있음.

    • Apache Tomcat을 사용하여 서버를 실행하면 기본 port 설정이 8080으로 되어있음

    • application.properties 파일에서 server.port=8081이렇게 설정을 하면 서버의 port 번호를 ‘8080’에서 ‘8081’로 바꿔서 실행시킬 수 있음.

Spring MVC


  • MVC란 Model-View-Controller의 약자로, 소프트웨어 디자인 패턴 중 하나

  • MVC 패턴은 소프트웨어를 구성하는 요소들을 Model, View, Controller로 구분하여 각각의 역할을 분리함.

1

  • Model

    • 데이터와 비즈니스 로직을 담당

    • 데이터베이스와 연동하여 데이터를 저장하고 불러오는 등의 작업을 수행

  • View

    • 사용자 인터페이스를 담당

    • 사용자가 보는 화면과 버튼, 폼 등을 디자인하고 구현

  • Controller

    • Model과 View 사이의 상호작용을 조정하고 제어

    • 사용자의 입력을 받아 Model에 전달하고, Model의 결과를 바탕으로 View를 업데이트

  • 📌 MVC 패턴은 소프트웨어를 구성하는 요소들을 분리함으로써 코드의 재사용성과 유지보수성을 높이고, 개발자들 간의 협업을 용이하게 함. 따라서 소프트웨어를 개발할 때, MVC 패턴을 적용하여 구조를 잘 설계하는 것이 중요함.

  • Spring MVC란?

    • Spring MVC에 대한 설명으로 ‘DispatcherServlet’이 중앙에서 HTTP 요청을 처리해주는데 이는 Front Controller 패턴으로 설계되어있다’라고 설명

    • 쉽게 표현해보자면 ‘Spring에서 MVC 디자인 패턴을 적용하여 HTTP 요청을 효율적으로 처리하고 있다’

  • DispatcherServlet에서 Servlet

    • Servlet (서블릿)은 자바를 사용하여 웹 페이지를 동적으로 생성하는 서버 측 프로그램 혹은 그 사양을 말함.

    1

      1. 사용자가 Client(브라우저)를 통해 서버에 HTTP Request 즉, API 요청을 함.
      1. 요청을 받은 Servlet 컨테이너는 HttpServletRequest, HttpServletResponse 객체를 생성.
        • a. 약속된 HTTP의 규격을 맞추면서 쉽게 HTTP에 담긴 데이터를 사용하기 위한 객체임.
      1. 설정된 정보를 통해 어떠한 Servlet에 대한 요청인지 찾음.
      1. 해당 Servlet에서 service 메서드를 호출한 뒤 브라우저의 요청 Method에 따라 doGet 혹은 doPost 등의 메서드를 호출함.
      1. 호출한 메서드들의 결과를 그대로 반환하거나 동적 페이지를 생성한 뒤 HttpServletResponse 객체에 응답을 담아 Client(브라우저)에 반환함.
      1. 응답이 완료되면 생성한 HttpServletRequest, HttpServletResponse 객체를 소멸
  • Front Controller

    • 모든 API 요청을 앞서 살펴본 서블릿의 동작 방식에 맞춰 코드를 구현한다면 무수히 많은 Servlet 클래스를 구현해야함.

    • 따라서 Spring은 DispatcherServlet을 사용하여 Front Controller 패턴 방식으로 API 요청을 효율적으로 처리하고 있음.

  • Front Controller 패턴의 동작과정

1

  • 1.Client(브라우저)에서 HTTP 요청이 들어오면 DispatcherServlet 객체가 요청을 분석함.

    1. DispatcherServlet 객체는 분석한 데이터를 토대로 Handler mapping을 통해 Controller를 찾아 요청을 전달해줌.

[Sample]

1
2
3
4
5
6
7
8
9
GET /api/hello  HelloController  hello() 함수

GET /user/login  UserController  login() 함수

GET /user/signup  UserController  signup() 함수

POST /user/signup  UserController  registerUser() 함수

  • Handler mapping 에는 API path 와 Controller 메서드가 매칭되어 있음
1
2
3
4
5
6
7
8
9
@RestController
public  class  HelloController {
	@GetMapping("/api/hello")
	public  String  hello() {
		return  "Hello World!";
	}

}

  • API path 즉, URL을 Controller에 작성하는 방법은 @Controller 애너테이션이 달려있는 클래스를 생성한 뒤 @GetMapping 처럼 요청한 HTTP Method 와 일치하는 애너테이션을 추가한 메서드를 구현함.

    • URL은 @GetMapping("/api/hello") 이처럼 해당 애너테이션의 속성값으로 전달해주면 됨.

    • 해당 메서드명은 URL을 매핑하는데 영향을 미치지 않음으로 자유롭게 정해도 상관 없음.

  • 이제는 직접 Servlet을 구현하지 않아도 DispatcherServlet에 의해 간편하게 HTTP 요청을 처리할 수 있게 되었음.

    1. ControllerDispathcerServlet
    • 해당 Controller는 요청에 대한 처리를 완료 후 처리에 대한 결과 즉, 데이터(‘Model‘)와 ‘View’ 정보를 전달함.
    1. DispatcherServletClient
  • ViewResolver 통해 View에 Model을 적용하여 View를 Client에게 응답으로 전달함.

Controller


Controller Code

  • 다행히 Spring MVC는 효율적인 API 처리를 위해 Front Controller 패턴을 만들어냈음.

  • 이제는 API 마다 파일을 만들 필요 없음.

    • 보통 하나의 Contoller 에 모든 API를 넣지는 않음.

    • 유사한 성격의 API 를 하나의 Controller 로 관리함.

  • 메서드 이름도 내 마음대로 설정 가능

1

  • return "hello World" 부분이 Model and logical view name임

  • @RequestMapping은 중복되는 URL를 단축시켜줄 수 있음

  • @GET, @POST, @PUT, @DELETE

    • 각각의 HTTP Method에 매핑되는 애너테이션

정적 페이지와 동적 페이지


  • 정적 페이지

1

    1. static 폴더
    1. Redirect
    1. Template engine 에 View 전달
  • 동적 페이지

1

데이터를 Client에 반환하는 방법


  • JSON 데이터 반환하는 방법
    • 템플릿 엔진이 적용된 SpringBoot에서는 Controller에서 문자열을 반환하면 templates 폴더에서 해당 문자열의 .html 파일을 찾아서 반환해줌.
    • 따라서 html 파일이 아닌 JSON 데이터를 브라우저에 반환하고 싶다면 해당 메서드에 @ResponseBody 애너테이션을 추가해줘야함.

📌 JSON 데이터 반환 방법

  • 반환값 : String
    • Java는 JSON 타입을 지원하지 않기 때문에 JSON 형태의 String 타입으로 변환해서 사용해야 함.
  • 반환값 : String 외 자바 클래스
    • Spring에서 자동으로 Java의 객체를 JSON으로 변환해줌.
  • @RestController = @Controller + @ResponseBody

    • @RestController를 사용하면 해당 클래스의 모든 메서드에 @ResponseBody 애너테이션이 추가되는 효과를 부여할 수 있음
  • 해당 클래스 내에서 뷰(html/css/js)를 반환해야 되는 경우가 있을 때 : @Controller, 바디에 @ResponseBody

  • html을 반환하는 것이 아니라 JSON 형태를 반환할 때는 @RestController를 사용하여 모든 메서드 전체에 ResponseBody가 적용되게 함.

Jackson


  • Jackson은 JSON 데이터 구조를 처리해주는 라이브러리

    • ObjectJSON 타입의 String으로 변환해줄 수 있음.

    • JSON 타입의 StringObject로 변환해줄 수 있음.

  • Spring은 3.0버전 이후로 Jacskon과 관련된 API를 제공함으로써, 우리가 직접 소스 코드를 작성하여 JSON 데이터를 처리하지 않아도 자동으로 처리해주고 있음.

    • 따라서 SpringBoot의 starter-web에서는 default로 Jackson 관련 라이브러리들을 제공하고 있음.

    • 직접 JSON 데이터를 처리해야할 때는 Jackson 라이브러리의 ObjectMapper를 사용할 수 있음.

  • Object To JSON

    • objectMapper의 writeValueAsString 메서드를 사용하여 변환할 수 있음.

    • 파라미터에 JSON으로 변환시킬 Object의 객체를 주면 됨.

  • ObjectJSON 타입의 String으로 변환하기 위해서는 해당 Object에 get Method가 필요함.

  • JSON To Object

    • objectMapper의 readValue 메서드를 사용하여 변환할 수 있습니다.

      • 첫 번째 파라미터는 JSON 타입의 String, 두 번째 파라미터에는 변환할 Object의 class 타입을 주면됩니다.
    • JSON 타입의 StringObject로 변환하기 위해서는 해당 Object에 기본 생성자와 get 혹은 set 메서드가 필요합니다.

Path Variable과 Request Param


  • Path Variable
    • Client 즉, 브라우저에서 서버로 HTTP 요청을 보낼 때 데이터를 함께 보낼 수 있음.
  • Request Param

    • 데이터를 받기 위해서는 ?name=Robbie&age=95 에서 key 부분에 선언한 name과 age를 사용하여 value에 선언된 Robbie, 95 데이터를 받아올 수 있음.
  • (@RequestParam String name, @RequestParam int age)

  • 해당 요청 메서드 파라미터에 @RequestParam 애너테이션과 함께 key 부분에 선언한 변수명과 변수타입을 선언하면 데이터를 받아올 수 있음.

추가 🕤


1

  • 오늘은 Spring 시작 날입니다. 정말 즐거워요…….

🐱‍🏍— —🤸🏻‍♀️ ~~~ 야~호~

This post is licensed under CC BY 4.0 by the author.