HTTP(HyperText Transfer Protocol)은 처음에는 HTML 문서 간의 연결을 위한 프로토콜로 시작되었으나, 지금은 거의 모든 데이터의 전송을 담당하고 있다.

🤔< HTTP와 데이터 전송 > 🤔

HTTP는 HTML,TEXT,IMAGE,음성,영상,파일,JSON,XML 등과 같은 다양한 형태의 데이터를 전송할 수 있다. 심지어는 서버 간에 데이터를 주고 받을 때도 대부분 HTTP를 사용한다. 이는 HTTP가 굉장히 다양한 형태의 데이터를 지원하고, 웹에서 가장 흔히 사용되는 프로토콜이기 때문이다.

🎁<HTTP의 역사를 통해 보는 발전>🎁

• HTTP/0.9(1991년):HTTP의 첫 번째 버전으로, 가장 기본적인 GET 메서드만 지원하였다. 또한 HTTP 헤더는 존재하지 않았다.
• HTTP/1.0(1996년): 이 버전에서는 다양한 메서드와 헤더가 추가되었다.
• HTTP/1.1(1997년):이는 가장 널리 사용되는 버전으로, 지금도 많은 곳에서 사용되고 있다.
• HTTP/2 (2015년): 이 버전에서는 HTTP/1.1의 성능 문제를 개선 하였다.
• HTTP/3: 이 버전은 아직 개발 중에 있으며, 이전 버전과 달리 UDP를 사용하여 통신한다. 이 변경의 목표는 통신의 성능을 더욱 향상시키는 것이다. 

[ 기반 프로토콜 ]

HTTP는 데이터를 전송하는 기반 프로토콜을 사용한다.

HTTP/1.1과 HTTP/2는 TCP를 기반으로 동작하는 반면, 개발 중인 HTTP/3은 UDP를 기반으로 동작한다.

이런 변화의 이유는 TCP가 비교적 느린 시작 속도(예: 3 way handshake)와 같은 특성 때문에, 더 빠른 데이터 전송을 위해 UDP를 사용하는 HTTP/3로 전환하는 것이다. 

< 실제 Web Browser에 사용 사례들 들여다 보기 >

실제로 어떤 것들이 HTTP를 통해 통신이 이루어지고 있는지 확인 할 수 있다. 웹 브라우저에서는 개발자 도구를 통해 이를 확인할 수 있다.

1.Web Browser를 열고 F12를 눌러 개발자 도구를 연 다음,

2.'Network' 탭을 선택하고,

3.Protocol'체크박스를 체크하면,

실제로 어떤 데이터가 어떤 HTTP 버전을 통해 전송되고 있는지 확인 할 수 있다.

아래의 사진과 같이 h3라는 것이 보일 것이다.

Reference : 모든 개발자를 위한 HTTP 웹 기본 지식

https://www.inflearn.com/

인터넷 브라우저를 이용해 웹 페이지를 열어볼 때 무슨 일이 일어날까? 예를 들어, 'https://www.google.com:443/search?q=hello&hl=ko' 라는 URL을 웹 브라우저에 입력하면 다음과 같은 단계들이 일어난다.

[ 1. DNS 조회(DNS Lookup) ]

먼저, 브라우저는 'www.google.com'이라는 도메인 이름을 이용해 해당 IP 주소를 찾아야 한다. 이 작업은 DNS(Domain Name System) 서버를 조회하여 진행한다. 예를 들어, 이 경우에는 DNS 서버가 'www.google.com'의 IP 주소를 '200.200.200.2'로 알려줄 수 있다. 

[ 2. 포트 번호 확인 ]

다음으로 브라우저는 웹 서버와 통신할 수 있는 '문'을 찾아야 하는데, 이 '문'이 바로 포트 번호이다. 보통 HTTPS 프로토콜은 443 포트를 사용한다. URL에서 ':443'이라고 명시되어 있으면 이는 HTTPS 프로토콜의 기본 포트인 443번을 사용하겠다는 의미이다.

[ 3. HTTP 요청 메세지 생성 ]

이제 브라우저는 웹서버에 정보를 요청하기 위한 HTTP 요청 메세지를 생성한다. 이 메세지는 요청 유형(GET,POST 등), 요청하는 URL, 사용하는 프로토콜 버전 등의 정보를 포함한다. 이 예시에서는 'hello'라는 단어를 한국어 페이지에서 검색하는 요청을 보내는 것이다. 이에 대한 HTTP 요청 메세지는 대략 다음과 같다.

GET /search?q=hello&hl=ko HTTP/1.1
Host: www.google.com

위의 사진과 같이, 요청 패킷이 도착하면 HTTPS 메세지를 받은 다음 해석을 한다.

https://www.google.com 같은 것을 해석 하여서 HTTP 응답 메세지를 만들어낸다.

Content Type이라는 것은 html 형식, UTF-8 형식등을 알 수 있고,

Content-Length은 html의 길이를 알 수 있다. 

이걸 받으면, HTMl 데이터가 들어 있으니, 웹 브라우저가 렌더링을 통하여 사용자가 화면을 볼 수 있다. 

Reference : 모든 개발자를 위한 HTTP 웹 기본 지식

https://www.inflearn.com/

클라이언트는 데이터베이스에 직접 접근할 수 없다. 그러니 이 역시도 API를 구현해볼 수 있도록 해야한다.

여기서는 블로그 글을 조회하기 위한 API를 구현한다. 모든 글을 조회하는 API,글 내용을 조회하는 API를 순서대로 구현한다.

<①.서비스 메서드 코드 작성하기>

BlogService.java 파일을 열어 데이터 베이스에 저장되어 있는 글을 모두 가져오는 findAll()메서드를 추가한다. 

JPA 지원 메서드인 findAll()을 호출해 article 테이블에 저장되어 있는 모든 데이터를 조회한다.  이제 요청을 받아 서비스에 전달하는 컨트롤러를 만들면 된다.

<②.컨트롤러 메서드 코드 작성하기>

/api/articles GET 요청이 오면 글 목록을 조회할 findAllArticles() 메서드를 작성한다. 이 메서드는 전체 글 목록을 조회하고 응답하는 역할을 한다.

1단계 : 응답을 위한 DTO를 먼저 작성한다. dto 디렉터리에 ArticleResponse.java 파일을 생성하고 다음과 같이 코드를 작성하면 된다. 

글은 제목과 내용 구성이므로 해당 필드를 가지는 클래스를 만든 다음, 엔티티를 인수로 받는 생성자를 추가 했다.

2단계 : Controller 디렉터리에 있는 BlogApiController.java 파일을 열어 전체 글을 조회한 뒤 반환하는 findAllArticles()메서드를 추가한다.

/api/articles GET 요청이 오면 글 전체를 조회하는 findAll() 메서드를 호출한 다음 응답용 객체인 ArticleResponse로 파싱해 body에 담아 클라이언트에게 전송한다. 이 코드에는 스트림을 적용하였다. (스트림은 자바 8의 기능으로 여러 데이터가 모여있는 컬렉션을 간편하게 처리하기 위한 기능이다.)

< 테스트 코드 작성하기 >

글 조회 테스트 역시 편의를 위해 테스트 코드 작성을 한다. 

Source :스프링 부트 3 백엔드 개발자 되기 - 자바 편

http://www.yes24.com/Product/Goods/118625612

개발을 하면서 테스트 과정을 계속 거쳐야 하는데, 매번 H2 콘솔 등에 접속해 쿼리를 입력해 데이터가 저장되는지. 실제로 들어 있는지 확인하는 등 이런 방식으로 테스트하려면 매우 불편하다. 이런 작업을 줄여줄 테스트 코드가 있다.

BlogApiController Class에 Alt+Enter를 누르고 [Create Test]를 누르면 테스트 생성 창이 열린다. 기본값을 그대로 두고 테스트 코드 파일을 생성하면 된다. 이 과정을 마치면 /test/java/패키지/아래에 BlogApiControllerTest.java 파일이 만들어 진다. 이 파일을 수정해보겠다.

ObjectMapper 클래스로 만든 객체는 자바 객체를 JSON 데이터로 변환하는 직렬화(serialization)또는 반대로 JSON 데이터를 자바에서 사용하기 위해 자바 객체로 변환하는 역직렬화(deserialization)할 때 사용한다.

< 자바 직렬화와 역직렬화 >

HTTP에서는 JSON을, 자바에서는 객체를 사용한다. 하지만 서로 형식이 다르기 때문에 형식에 맞게 변환하는 작업이 필요하다. 이런 작업들을 직렬화,역직렬화라고 한다. ① 직렬화란 자바 시스템 내부에서 사용되는 객체를 외부에서 사용하도록  데이터를 변환하는 작업을 이야기한다. 예를 들어 title은 "제목", content는 "내용"이라는 값이 들어 있는 객체가 있다고 가정을 들겠다. 이때 이 객체를 JSON 형식으로 직렬화할 수 있다. ② 역직렬화는 직렬화의 반대이다. 외부에서 사용하는 데이터를 자바 객체 형태로 변환하는 작업을 이야기한다. JSON 형식의 값을 자바 객체에 맞게 변환하는 것도 역직렬화 이다.

이제 블로그 글 생성 API를 테스트하는 코드를 작성하면 된다. given-when-then 패턴을 생성할 코드의 내용은 다음과 같다.

BlogApiControllerTest.java 파일에 작성하면 된다.

writeValueAsString() 메서드를 사용해서 객체를 JSON으로 직렬화해준다. 그 이후에는 MockMvc를 사용해 HTTP 메서드, URL,요청  본문,요청 타입등을 설정한 뒤 설정한 내용을 바탕으로 테스트 요청을 보낸다. contentType() 메서드는 요청을 보낼 때 JSON, XML등 다양한 타입 중 하나를 골라 요청을 보낸다. 여기에서 JSON 타입의 요청을 보낸다고 명시했다.

assertThat() 메서드로는 블로그 글의 개수가 1인지 확인한다. 자주 사용하는 메서드는 표로 정리하였다.

테스트 코드를 실행해 코드가 잘 동작하는지 확인한다.

isEqualTo 기대값을 2로 바꿀려면,  요청을 두번 보내면 된다.

Source :스프링 부트 3 백엔드 개발자 되기 - 자바 편

http://www.yes24.com/Product/Goods/118625612

🔥<URI(Uniform Resource Identifier)>🔥

리소스를 식별하는 가장 큰 개념. "리소스"라는 단어는 웹브라우저에 있는 HTML,File,실시간 교통정보와 같은 모든 것을 포괄한다. 이런 리소스를 식별하는 방법이 바로 URI이다. URI를 통해 인터넷의 모든 자원을 식별하고 구별할 수 있다.

이런 개념을 더 쉽게 이해하려면, 사람의 주민번호를 생각하면 쉽다. 각 사람마다 고유한 주민번호가 있어서 각각의 사람을 쉽게 구별하고 쉽게 식별할 수 있다.  URI도 이런 역할을 한다.

그러나 URI는 다시 두 가지 하위 개념으로 나뉜다. URL(Uniform Resource Locator)과 URN(Uniform Resource Name)이다.

URL은 리소스의 위치를 지정하는 방법이다. 예를 들어

https://www.google.com/search?q=hello&hl=ko

이 링크는 구글에서 "hello"를 검색하는 페이지의 위치를 지정하는 URL이다. 다시 말해, URL은 특정 웹페이지에 도달하는 방법을 제공한다.

반면에 URN은 리소스에 이름을 부여하는 방법이다. URN은 URL과 달리 위치에 의존하지 않는다. 즉, 리소스의 위치가 변하더라도 URN은 변하지 않는다. 하지만, 이름만으로 실제 리소스를 찾는 방법이 보편화되지 않아 URN은 실제로는 잘 사용되지 않는다.

이런 이유로, 보통의 경우 URI와  URL을 같은 의미로 사용한다.

< URL 문법 구조 >

URL의 기본 구조는 다음과 같다.

scheme://[userinfo@]host[:port][/path][?query][#fragment]

"scheme": 프로토콜을 의미한다. 어떤 방식으로 자원에 접근할 것인가를 나타낸다. 예를 들면 http,https,ftp 등이 있다.

"[userinfo@]": URL에 사용자 정보를 포함해야 하는 경우 사용한다. 그러나 이 부분은 거의 사용되지 않는다.

"host[:port]":호스트 이름과 포트 번호를 나타낸다. 포트 번호는 생략 가능하며, 생략시 http는 80,https는 443을 기본으로 사용한다.

"[/path]":자원의 경로를 나타낸다.  계층적 구조로 표현할 수 있으며, 자원의 위치를 더욱 명확하게 나타낸다.

"[?query]": URL에 포함된 쿼리를 나타낸다. "key=value"형태로 이루어져 있으며, 여러 개의 쿼리는 "&"로 연결한다.

"[#fragment]": 페이지 내부 북마크 등에 사용된다. URL의 특정 부분을 가리키는 데 사용된다.

Reference : 모든 개발자를 위한 HTTP 웹 기본 지식

https://www.inflearn.com/course/lecture?courseSlug=http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC&unitId=61357&tab=curriculum 

우리는 매일 수없이 많은 웹사이트를 방문한다. 이 과정에서 우리가 입력하는 것은 대부분 도메인 이름이며, 이는 우리에게 익숙하고 기억하기 쉽게 만들어진 주소이다.하지만 컴퓨터와 서버 사이의 실질적 통신은 이 도메인 이름이 아닌 IP 주소를 통해 이루어진다.

그런데 여기서 문제가 있다. IP 주소는 변경될 수 있으며, 그렇다면 웹 사이트의 IP 주소가 바뀐다면 어떻게 해당 웹사이트로 접속할 수가 있는 것일까? 이에 대한 해답은 오늘의 주제인 DNS, 즉 도메인 이름 시스템(Domain Name System)에 있다.

🌳 < DNS > 🌳

DNS는 이름 그대로 도메인 이름을 IP 주소로 바꿔주는 시스템이다. 이 시스템의 중요성을 이해하려면, 우선 IP 주소의 중요성을 이해해야만 한다. IP 주소는 인터넷 상의 각 컴퓨터나 서버에 부여되는 고유한 식별자로, 이를 통해 데이터 패킷이 올바른 목적지로 전달된다. 하지만, IP 주소는 사람에게는 외우기 어렵고, 무엇보다 고정적이지 않을 수 있다.

그래서 DNS는 사람이 기억하기 쉬운 도메인 이름을 기계가 이해할 수 있는 IP주소로 변환하는 역할을 한다.

이렇게 함으로써 사용자는 웹 사이트의 IP 주소가 변경되더라도 도메인 이름만 알고 있다면 문제없이 해당 웹사이트에 접속할 수 있게 된다.

예를 들어, "google.com"이라는 도메인 이름을 가진 웹사이트에 접속하려고 할 때, 우리의 컴퓨터는 먼저 DNS 서버에게 "google.com"의 IP 주소를 물어본다. DNS 서버는 이에 대한 답으로 해당 도메인의 IP주소, 예를 들어 "200.200.200.2"를 응답하게 된다. 그런 다음, 우리의 컴퓨터는 이 IP 주소를 통해 실제로 Google 서버에 접속하게 된다.

정리하자면, DNS는 우리가 인터넷을 쉽게 이용할 수 있도록 해주는 매우 중요한 시스템이다. 이를 통해 우리는 복잡하고 어려운 IP 주소 대신에 익숙하고 기억하기 쉬운 도메인 이름을 사용할 수 있게 된다.

Reference : 모든 개발자를 위한 HTTP 웹 기본 지식

https://www.inflearn.com/

데이터가 네트워크를 통해 이동하는 것은 컴퓨터를 하면서 굉장히 중요한 부분중 하나이다.

컴퓨터를 이용해서 게임을 하거나 화상통화를 하거나 웹브라우저를 사용하는 모든 행동들은 네트워크 상의 데이터 패킷들을 주고 받는 과정에 기반을 두고 있다. 하지만, 이 모든 데이터 들이 우리의 컴퓨터에 동시에 도착하면, 어떻게 컴퓨터는 그들이 각기 어떤 애플리케이션에 속한 데이터인지 알 수 있을까?

이 질문에 대한 답은 TCP/IP 프로토콜과 포트(port)이다.

TCP/IP는 인터넷 프로토콜 스위트로서, 그 중심에는 두 가지 기본적인 프로토콜인 TCP가 있다. IP는 인터넷 프로토콜로서 데이터 패킷을 올바른 목적지로 보내는 데 쓰이며, TCP는 패킷들이 올바르게, 순서대로 도착했는지 확인하는 역할을 한다.

TCP/IP 패킷은 출발지 IP, 출발지 PORT, 목적지 IP, 목적지 PORT 등을 포함한다. 

그렇다면 이 "PORT"라는 것은 무엇일까?

🤔 < PORT > 🤔

포트는 한 컴퓨터 내에서 네트워크 통신을 처리하는 여러 프로세스들을 구분하기 위한 개념이다.

각 애플리케이션은 고유한 포트 번호를 가지고 있으며, 이를 통해 동시에 수신된 데이터 패킷들을 알맞은 애플리케이션으로 정확하게 전달할 수 있다.

예를 들어, A라는 사람이 게임을 하며 8090번 포트를 사용하고 있고, 동시에 친구들과 화상통화를 하면서 21000번 포트를 사용하면서, 또 웹브라우저는 10010번 포트를 이용하고 있다면, 이 모든 데이터 패킷들은 각각의 포트 번호를 통해 올바른 애플리케이션으로 정확하게 전달될 것이다.

패킷이 발신될 때, 그 출발지 IP와 포트 정보도 함께 보내지기 때문에, 응답 패킷은 이 정보를 바탕으로 원래의 발신자에게 정확하게 돌아갈 수 있다.

포트 번호는 0에서 65535까지의 범위에서 할당될 수 있으며, 0에서 1023까지의 범위는 잘 알려진 포트로 예약되어 있다.

이 범위의 포트는 일반적으로 특정 서비스나 프로토콜에 대응된다. 예를 들어, FTP는 20과 21번, Telnet은 23번, HTTP는 80번, HTTPS는 443번 포트를 사용한다. 이 범위의 포트는 특별한 목적을 위해 예약되어 있으므로, 일반적으로 사용자 정의 애플리케이션에는 사용하지 않는 것이 좋다.

TCP/IP와 포트의 개념을 이해하면, 컴퓨터가 동시에 다양한 애플리케이션의 데이터를 어떻게 처리하는지 이해할 수 있게 된다.

Reference :모든 개발자를 위한 HTTP 웹 기본 지식

https://www.inflearn.com/

Port kill 하는 이유 : 가끔씩 Intellij나 다른 IDE 사용 시, 기존에 사용하고 있던 포트가 있을 시, 접속이 안되는 경우.

Powershell 실행

netstat -ano | findstr :9080 < 붙여넣기

9080은 port번호니까 localhost:5500이면 5500을 넣어주면 된다.

PS C:\Users\mypc> netstat -ano | findstr :9080

TCP 0.0.0.0:9080 0.0.0.0:0 LISTENING 9328

TCP [::]:9080 [::]:0 LISTENING 9328

이런 출력 결과가 나오는데 LISTENING 뒤에 값을 기억한다.

taskkill /pid 9328 /f

이렇게 하면 Port Kill이 된다.

pid 뒤 숫자에 LISTENING 번호를 기입해주면 된다.

이전 글에서 엔티티 구성이 끝났으니 API를 하나씩 구현할 예정이다. 구현 과정은 서비스 클래스에서 메서드를 구현하고, 컨트롤러에서 사용할 메서드를 구현한 다음, API를 실제로 테스트할 것이다. 그림으로 보면 다음과 같다. 

[서비스 메서드 코드 작성 하기] 

먼저 서비스 계층에 블로그에 글을 추가하는 코드를 작성한다. 서비스 계층에서 요청을 받을 객체인 AddArticleRequest 객체를 생성하고, BlogService 클래스를 생성한 다음에 블로그 글 추가 메서드인 save()를 구현하겠다.

먼저 springbootdeveloper 패키지에 dto 패키지를 생성한 다음, dto 패키지를 컨트롤러에서 요청 본문을 받을 객체인 AddArticleRequest.java 파일을 생성한다. DTO는 계층끼리 데이터를 교환하기 위해 사용하는 객체다. 앞서 DAO를 언급했는데, DAO는 데이터베이스와 연결되고 데이터를 조회하고 수정하는데 사용하는 객체라 데이터 수정과 관련된 로직이 포함되지만 DTO는 단순하게 데이터를 옮기기 위해 사용하는 전달자 역할을 하는 객체이기 때문에 별도의 비즈니스 로직을 포함하지 않는다. 코드를 작성하는 김에 참고로 알아두기 바란다.

toEntity()는 빌더 패턴을 사용해 DTO를 엔티티로 만들어주는 메서드이다. 이 메서드는 추후에 블로그 글을 추가할 때 저장할 엔티티로 변환하는 용도로 사용한다.

springbootdeveloper 패키지에 service 패키지를 생성한 뒤, service 패키지에서 BlogService.java를 생성해 BlogService 클래스를 구현한다.

@RequiredArgsConstructor는 빈을 생성자로 생성하는 롬복에서 지원하는 Annotation이다.  final 키워드나 @NotNull이 붙은 필드로 생성자를 만들어준다. @Service 애너테이션은 해당 클래스를 빈으로 서블릿 컨테이너에 등록해준다. save()메서드는 JpaRepository에서 지원하는 저장 메서드 save()로 AddArticleRequest 클래스에 저장된 값들을 article 데이터베이스에 저장한다. 

[컨트롤러 메서드 코드 작성하기]

이제 URL에 매핑하기 위한 컨트롤러 메서드를 추가한다. 앞서 컨트롤러 메서드를 구현한 적이 있는데. 다시 복습하자면 컨트롤러 메서드에는 URL 매핑 애너테이션 @GetMapping, @PostMapping, @PutMapping, @DeleteMapping 등을 사용할 수 있다. 이름에서 볼 수 있듯이 각 메서드는 HTTP 메서드에 대응한다. 여기에서는 /api/articles에 POST요청이 오면 @PostMapping을 이용해 요청을 매핑한 뒤, 블로그 글을 생성하는 BlogService의 save() 메서드를 호출한 뒤, 생성된 블로그 글을 반환하는 작업을 할 addArticle() 메서드를 작성한다. 

@RestController Annotation을 클래스에 붙이면 HTTP 응답으로 객체 데이터를 JSON 형식으로 반환한다.

@PostMapping() 애너테이션은 HTTP 메서드가 POST일 때 요청받은 URL와 동일한 메서드와 매핑한다.

지금의 경우 /api/articles는 addArticle()메서드에 매핑한다.

@RequestBody 애너테이션은 HTTP를 요청할 때 응답에 해당하는 값을 @RequestBody 애너테이션이 붙은 대상 객체인 AddArticleRequest에 매핑한다. ResponseEntity.status().body()는 응답 코드로 201, 즉, Created를 응답하고 테이블에 저장된 객체를 반환한다.

Reference : Reference : 출처 : 스프링 부트 3 백엔드 개발자 되기 - 자바 편

http://www.yes24.com/Product/Goods/118625612

< 엔티티 구성하기  >

만들 엔티티와 매핑되는 테이블 구조는 다음과 같다.

springbootdeveloper 패키지에 domain 패키지를 새로 만들고 domain 패키지에 Article.java파일을 만든 다음, 코드를 작성했다. 

@Builder 애너테이션은 롬복에서 지원하는 Annotation인데, 이 Annotation을 생성자 위에 입력하면 빌더 패턴 방식으로 객체를 생성할 수 있어 편리하다.

빌더 패턴을 사용하면 객체를 유연하고 직관적으로 생성할 수 있기 때문에 개발자들이 애용하는 디자인 패턴이다. 즉, 빌더 패턴을 사용하면 어느 필드에 어떤 값이 들어가는지 명시적으로 파악할 수 있다.

다음 코드 예를 보겠다.

// 빌더 패턴을 사용하지 않았을 때
new Article("abc", "def");


//빌더 패턴을 사용했을 때
Article.builder()
 .title("abc")
 .content("def")
 .build();

예를 들어 위에서 작성한 Article 객체를 생성할 때 title에는 abc를, content에는 def값으로 초기화한다고 하겠다.

빌더 패턴을 사용하지 않으면 abc는 어느 필드에 들어가는 값인지, def는 어디 필드에 들어가는 값인지 파악하기가 어렵다. 하지만 빌더 패턴을 사용하면 어느 필드에 어느 값이 매칭되는지 바로 보이므로 객체 생성 코드의 가독성을 높인다. 그리고 @Builder 애너테이션을 사용하면 빌더 패턴을 사용하기 위한 코드를 자동으로 생성하므로 간편하게 빌더 패턴을 사용해 객체를 만들 수 있는 것이다.

이제 위의 코드에 롬복을 사용해서 코드가 더 깔끔하게 바뀌는지 확인해볼 차례다. getId(),getTitle() 같이 필드의 값을 가져오는 게터 메서드들은 public class Article 위에 @Getter 애너테이션, @NoArgsConstructor 애너테이션으로 대치한다. protected Article() {} 코드블록, get 관련 메서드는 모두 삭제하면 된다.

코드를 보면 @NoArgsConstructor 애너테이션을 선언해 접근 제어자가 protected인 기본 생성자를 별도의 코드 없이 생성했고, @Getter 애너테이션으로 클래스 필드에 대해 별도 코드 없이 생성자 메서드를 만들 수 있게 되었다.

이렇게 롬복의 애너테이션을 사용하니까 코드를 반복해 입력할 필요가 없어져서 가독성이 향상 되었다.

< Repository 만들기 >

springbootdeveloper 패키지에 repository 패키지를 새로 만든 다음, repository 패키지에서 BlogRepository.java 파일을 생성해 BlogRepositoryt 인터페이스를 만들었다.

Reference : Reference : 출처 : 스프링 부트 3 백엔드 개발자 되기 - 자바 편

http://www.yes24.com/Product/Goods/118625612