뚝딱뚝딱

HTTP Request Methods란?
클라이언트가 웹서버에게 요청하는 목적 및 그 종류를 알리는 수단을 말한다.

1. GET
   URL(URI) 형식으로 서버 측에 리소스를 요청한다.
   리소스(데이터)를 받기 위함
2. HEAD
   GET과 유사하지만, HEAD는 실제 문서 요청이 아닌 문서에 대한 정보 요청이다.
   즉, Response 메세지를 받았을 때, Body는 비어있고, Header 정보만 들어있다.
   메세지 헤더 정보를 받기 위함
   
   
3. POST
   클라이언트에서 서버로 어떤 정보를 제출하기 위해 사용한다.
   Request 데이터를 HTTP Body에 담아 웹 서버로 전송한다.
   내용 및 파일 전송을 하기 위함
   
   
4. PUT
   POST와 유사하나, 기존 데이터를 갱신할 때 사용한다.
   리소스(데이터)를 갱신하기 위함
   
   
5. DELETE
   웹 서버측에 요청한 리소스를 삭제할 때 사용한다.
   (실제로 클라이언트에서 서버 자원을 삭제하도록 하진 않아 비활성화로 구성한다.)
   리소스(데이터)를 삭제하기 위함
   
   
6. CONNECT
   보통 Proxy를 통해 SSL 통신을 하고자할 때 사용한다.
   클라이언트와 서버 사이의 중간 경유를 위함
   
   
7. OPTIONS
   웹 서버 측에서 지원하고 있는 메소드가 무엇인지 알기 위해 사용한다.
   서버 측 제공 메소드에 대한 질의를 하기 위함
   
   
8. TRACE
   웹 서버로부터 받은 내용을 확인하기 위해 loop-back 테스트를 할 때 사용한다.
   Request 리소스가 수신되는 경로를 보기 위함
   
   
9. PATCH
   PUT과 유사하나, 모든 데이터를 갱신하는 것이 아닌 리소스의 일부분만 수정할 때 쓰인다.
   리소스(데이터)의 일부분만 갱신하기 위함

***참고
https://gyoogle.dev/blog/web-knowledge/HTTP%20Request%20Methods.html

쿠키

• 저장 위치 
  클라이언트의 웹 브라우저가 지정하는 메모리 or 하드디스크
  (브라우저 : 크롬, 네이버웨일, edge 등과 같은 것)
• 만료 시점
  저장할 때 expires 속성을 정의해 무효화시키면 삭제될 날짜를 정할 수 있음
• 리소스
  클라인언트에 저장되고 클라이언트의 메모리를 사용하기 때문에 서버 자원을 사용하지 않음
• 용량 제한
  클라이언트도 모르게 접속되는 사이트에 의하여 설정될 수 있기 때문에 쿠키로 인해 문제가 발생하는 것을 막고자 한 도메인당 20개, 하나의 쿠키 당 4KB로 제한해 둠
• 1. 사용자가 웹사이트에 처음 방문하면 서버에서 클라이언트에게 쿠키(고유한 식별자)를 생성하고 전송함.
  2. 클라이언트는 받은 쿠키를 브라우저에 저장함.
  3. 이후 사용자가 같은 웹사이트를 방문할 때, 브라우저는 저장된 쿠키를 함께 서버로 전송함.
• 예를 들어, 어떤 웹 페이지에 방문하여 로그인을 한 뒤, 동일한 웹 페이지를 방문하였을 때 로그인 상태가 유지되어 있는 이유는 브라우저가 처음에 저장한 쿠키를 두번째 방문 때 서버로 주었기 때문임! 이때 서버는 고유한 식별자로서 구분하고 이전에 로그인한 사용자임을 알아챌 수 있음!

세션

• 저장위치
  서버의 메모리에 저장
• 만료 시점
  클라이언트가 로그아웃하거나, 설정 시간동안 반응이 없으면 무효화 되기 때문에 정확한 시점을 알 수 없음
• 리소스
  세션은 서버에 저장되고, 서버 메모리로 로딩 되기 때문에 세션이 생길 때마다 리소스를 차지함
• 용량 제한
  클라이언트가 접속하면 서버에 의해 생성되므로 개수나 용량 제한이 없음
• 세션은 서버 측에서 상태를 유지하기 위한 메커니즘임.
• 각 세션은 고유한 식별자(session ID)로 구분되며, 이 식별자를 통해 서버는 사용자를 식별하고 해당 세션과 연결된 데이터를 유지함.
• 1. 사용자가 웹사이트에 접속하면 서버는 고유한 세션 ID를 생성하고 클라이언트에게 전송함.
  2. 클라이언트는 이 세션 ID를 쿠키 또는 URL 매개변수 등을 통해 저장함.
  3. 사용자의 요청이 서버에 도달하면, 서버는 세션 ID를 사용하여 해당 세션과 연결된 데이터에 접근함.
• 예를 들어, 클라이언트가 서버에 요청을 보낼 때, 서버는 세션 ID를 사용하여 해당 세션에 저장된 정보를 가져와 로그인 상태를 확인합니다. 따라서 로그인 정보나 장바구니 같은 경우의 정보를 불러온다.

쿠키와 세션을 이용한 로그인 메커니즘

사용자가 로그인한 후에는 브라우저가 쿠키를 저장하고, 이후에 해당 웹 페이지를 방문할 때 브라우저가 저장한 쿠키를 함께 서버로 전송하여 서버는 사용자를 식별하고 세션을 통해 로그인 상태를 유지한다.

1. 로그인 요청: 사용자가 로그인 페이지에서 로그인 정보(일반적으로 사용자명과 암호)를 입력하면, 서버는 이 정보를 받아 인증을 진행한다.
2. 쿠키 및 세션 생성: 인증이 성공하면 서버는 클라이언트(브라우저)에게 고유한 식별자인 쿠키를 생성하고 응답으로 전송합니다. 이 쿠키는 클라이언트 측에서 저장되어 나중에 사용자를 식별하는 데 사용된다. 또한, 서버는 사용자와 관련된 정보를 저장하고 세션 ID를 생성하여 이를 클라이언트에게 전송한다.
3. 쿠키 저장: 클라이언트(브라우저)는 받은 쿠키를 저장한다. 일반적으로 쿠키는 브라우저의 쿠키 저장소에 저장된다.
4. 이후 요청에서 쿠키 전송: 사용자가 이후에 해당 웹 페이지나 다른 페이지를 요청할 때, 브라우저는 저장한 쿠키를 요청과 함께 서버로 전송한다.
5. 서버에서 로그인 상태 확인: 서버는 받은 쿠키를 확인하여 해당 사용자를 식별하고, 세션을 통해 사용자의 로그인 상태를 확인한다.

이러한 과정을 통해 사용자는 로그인 후에도 쿠키와 세션을 통해 로그인 상태를 유지하게 된다.

이는 사용자 경험을 향상시키고, 로그인 정보를 보안적으로 관리하기 위한 일반적인 방법 중 하나이다.

*** Gyoogle 님 블로그를 참고하였습니다.

우리가 주소창에 주소를 입력하고 해당 페이지로 이동하여 화면에 보여지는 과정은 어떻게 이루어질까?

• 주소창에 url을 입력하고 enter를 누르면, 서버에 요청이 전송된다.
• 해당 페이지에 존재하는 여러 자원들 (text, image 등등)이 보내진다.
• 이제 브라우저는 해당 자원이 담긴 html과 스타일이 담긴 css를 W3C 명세에 따라 해석할 것이다.
  => 이 역할을 하는 것이 "렌더링 엔진"
• 렌더링 엔진은 우선 html 파싱 과정을 시작한다. html 파서가 문서에 존재하는 어휘와 구문을 분석하면서 DOM 트리를 구축한다.
• 다음엔 css 파싱 과정을 시작한다. css 파서가 모든 css 정보를 스타일 구조체로 생성한다.
• 이 2가지를 연결시켜 렌터 트리를 만든다.
  => 렌더링 엔진을 통해 (DOM 트리 + 스타일 구조체 = 렌더 트리)를 만든다!!
• 즉 렌더 트리를 통해 문서가 시각적 요소를 포함한 형태로 구성된 상태가 된다.
• 화면에 배치를 시작하고, UI 백엔드가 노드를 돌며 형상을 그린다.
• 이때 빠른 브라우저 화면 표시를 위해 '배치와 그리는 과정'은 페이지 정보를 모두 받고 한꺼번에 진행되지 않는다.
• 자원을 전송 받으면, 기다리는 동시에 일부분 먼저 진행하고 화면에 표시한다.
  => 우리가 웹 페이지에 접속할 때 한꺼번에 뜨지 않고 점점 화면에 나오는 것이 이 때문이다!!

***아래는 각 단계에서의 세부 동작에 관한 내용이다

브라우저 주요 기능

브라우저는 html과 css 명세에 따라 html 파일을 해석해서 표시한다.

이 "명세"는 웹 표준화 기구인 W3C(world wide web consortium)에서 정해진다.

예전 브라우저들은 일부만 명세에 따라 구현하고 독자적 방법으로 확장했음 -> 결국 심각한 호환성 문제가 발생하고, 요즘은 대부분 모두 표준 명세를 따름

브라우저가 가진 인터페이스는 보통 비슷비슷한 요소들이 존재한다.

** 브라우저가 가진 인터페이스는 아래와 같은 것들

시간이 지나면서, 사용자에게 필요한 서비스들로 서로 모방하며 갖춰지게 된 것

• URI 입력하는 주소 표시 줄
• 이전 버튼, 다음 버튼
• 북마크(즐겨찾기)
• 새로 고침 버튼
• 홈버튼...등등

브라우저 기본 구조

• 사용자 인터페이스
  주소 표시줄, 이전/다음 버튼, 북마크 등 사용자가 활용하는 서비스들 (요청한 페이지를 보여주는 창을 제외한 나머지 부분)
• 브라우저 엔진
  사용자 인터페이스와 렌더링 엔진 사이의 동작 제어
• 렌더링 엔진
  요청한 콘텐츠 표시 (html 요청이 들어오면? -> html, css 파싱해서 화면에 표시)
• 통신
  http 요청과 같은 네트워크 호출에 사용 (플랫폼의 독립적인 인터페이스로 구성되어 있음)
• UI 백엔드
  플랫폼에서 명시하지 않은 일반적 인터페이스. 콤보 박스 창 같은 기본적 장치를 그림
• 자바스트립트 해석기
  자바스트립트 코드를 해석하고 실행
• 자료 저장소
  쿠키 등 모든 종류의 자원을 하드 디스크에 저장하는 계층

렌더링이란?

렌더링 엔진은 요청받은 내용을 브라우저 화면에 표시해준다.

기본적으로 html, xml 문서와 이미지를 표시할 수 있다.

추가로 플러그인이나 브라우저 확장 기능으로 pdf 등 다른 유형도 표시가 가능하다.

(확장이 필요한 유형은 바로 뜨지 않고 팝업으로 확장 여부를 묻는 것을 볼 수 있다)

렌더링 엔진 종류

• 크롬, 사파리 : 웹킷(Webkit) 엔진 사용
• 파이어폭스 : 게코(Gecko) 엔진 사용

웹킷(Webkit) : 최초 리눅스 플랫폼에 동작하기 위한 오픈소스 엔진

렌더링 동작 과정

DOM : Document Object Model (문서 객체 모델)
DOM은 웹 브라우저가 html 페이지를 인식하는 방식

파싱

문서 파싱은, 브라우저가 코드를 이해하고 사용할 수 있는 구조로 변환하는 것이다.

문서를 가지고 어휘분석과 구문 분석 과정을 거쳐 파싱 트리를 구축한다.

*** Gyoogle.com 글을 참고하였습니다.

이전 내용↓↓↓

2023.11.22 - [Web Application/Backend] - [REST API] Spring Boot로 REST API CRUD 간단 구현 (4)-예외처리/handle Exception

응답 형태를 사용자가 원하는 형태로 받을 수 있도록 ResponseEntity를 커스텀하기!

이전에는 get을 통해 특정 cloudvendor의 정보를 불러들일 때 아래와 같이 4가지 속성에 대한 정보만 나왔다.

왜냐하면, 컨트롤러의 get 메서드에서 CloudVendor 서비스의 get메서드를 통해 데이터베이스에 있는 데이터를 가져오기 때문이다.

나는 컨트롤러의 get 메서드를 호출하면, 위의 데이터 뿐만아니라 httpStatus와, 특정 메시지도 가져오도록 하고 싶다면??

ResponseEntity를 세가지를 담도록 커스텀해주면 된다!

다른 형태로 담고싶다면 그것대로 커스텀해주면 된다.

아래 절차를 따라 ResponseEntity를 커스텀하고 다시 get을 통해 확인해보자!

💡 ResponseEntity 커스텀하기

1. response 패키지를 생성해준 후, ResponseHandler 클래스를 생성해준다.

2. ResponseHandler 클래스안에 reponseBuilder 메서드를 정의해준다.

public static ResponseEntity<Object> responseBuilder(
            String message, HttpStatus httpStatus, Object responseObject
    )

• 이 메서드는 responseHandler 객체를 생성하지 않아도 사용할 수 있도록, static으로 선언해준다.
• ResponseEntity를 사용자 입맛대로 커스텀해줄 것이기 때문에, ResponseEntity를 반환하도록 한다.
• 이 메서드의 인자로는 string타입의 message와, HttpStstus와, 임의의 데이터인 Object타입의 responseObject를 갖는다.

3. responseBuilder 메서드의 로직은 다음과 같이 동작할 수 있다.

{
        Map<String, Object> response = new HashMap<>();
        response.put("message", message);
        response.put("httpStatus", httpStatus);
        response.put("data", responseObject);

        return new ResponseEntity<>(response, httpStatus);
    }

• string과 object를 속성으로 갖는 Map을 하나 생성하여 HashMap으로 생성한다.
• 인자로 받은 것들을 Map에 message, httpStatus, reponseObject로 갖도록 한다.
• 그리고 ResponseEntity로 map과 httpStatus를 담아 반환한다. 

4. ResponseHandler 클래스의 코드 전문이다.

💡 커스텀한 ResponseEntity를 반환하도록 컨트롤러 수정하기

• getCloudVendorDetails함수는 원래 url로 특정 vendorId가 들어오면, CloudVendor 엔티티 객체를 반환하도록 되어있었다.
• 그러나, 지금은 커스텀한 ResponseEntity를 통해, 위와 같이 "특정 메시지"와 HttpStaus.OK와 기존의 데이터인 CloudVendor 엔티티 객체를 responseBuilder메서드의 인자로 넣어 커스텀한 ResponseEnity로 반환되도록 수정해주었다.
• 이 get 메서드에서 바뀐 부분은 반환타입이 커스텀한 ResponseEnity라는 것이다.

💡 결과 확인

• spring boot를 실행하고, postman에서 C5에 대해서 get mapping 해준다
• mapping 결과 다음과 같이 data, httpStatus, message가 모두 반환되었다.

• 이로써 내가 커스텀한대로 Response의 형태가 바뀌어 반환된 것을 확인할 수 있다.

↓↓↓ 다음 내용

2023.12.30 - [Web Application/Backend] - [REST API] Spring Boot로 REST API CRUD 간단 구현 (6) - JUnit TEST 기본 설정 및 repository 계층 test 예제

이전 내용↓↓↓

2023.11.13 - [Web Application/Backend] - [REST API] Spring Boot로 REST API CRUD 간단 구현 (3)

이전 포스팅에서 cloudVendor의 기본적인 CRUD가 동작하는 것을 확인하였다.

그런데 get mapping에서 cloud vendor가 존재하지 않을 때는 출력 시 오류가 발생하는 것을 확인하였다.

오늘은 이러한 오류가 발생했을 때, 즉 예외에 대해서는 어떻게 처리해야 하는지에 대해 알아볼 것이다.

✔ 웹 개발에 있어서 중요한 점

✅ 오류나 예외 상황 발생 시 사용자가 이해하기 쉽도록 상황에 대한 정보를 충분히 전달할 수 있어야 한다.

따라서 개발자는 로직 구현에 있어서 예외가 발생하는 부분을 찾아서, 예외처리를 해주어야 한다.

이제 프로젝트에서 발생한 오류를 가지고 예외처리를 해보자.

예외 처리를 하기 전에는 위와 같이 데이터베이스에 C3가 없을 때, C3를 get하는 mapping과정에서 반환 값이 없어서 에러가 발생하였다.

우리는 이를 CloudVendorNotFoundException이라고 할 것이다.

이 예외를 처리하기 위해서 다음 단계를 따른다.

1. 예외 처리를 위한 클래스들을 담은 exception 패키지를 하나 생성한다.

2. exception 패키지에 CloudVendorNotFoundException 클래스를 생성한다.

• 이 클래스를 예외 클래스로 인식하기 위해서 RuntimeException 클래스를 extends한다.
• 이 클래스에 대한 두 타입의 생성자를 자동생성해준다.
  - 인자로 message만 담은 생성자
  - 인자로 message와 Throwable 객체인 cause를 담은 생성자

*Throwable이 뭐야? (접은글을 확인하세요)

3. 클라이언트에게 예외 정보를 전달하기 위해서, 정보를 담는 CloudVendorException 클래스를 생성한다.

• 위 3개의 속성을 추가해준다. 
• 사용자에게 보여질 오류 메시지 = message
• 예외 정보 = throwable
• http 상태 정보 = httpStatus

• 기본 생성자와, getter들을 자동 생성해준다.

4. 이제 예외 처리를 할 CloudVendorExceptionHandler 클래스를 생성해준다. 프론트와 직접 연결되는 컨트롤러라고 생각하면 된다.

• 우리는 지금 CloudVendor를 찾을 수 없다는 예외에 대한 처리를 다루어야 하기 때문에, handleCloudVendorNotFoundException 메서드를 선언해주자.
• rest api이기 때문에 반환타입은 ResponseEntity로 하고, Object유형으로 반환하도록 한다.
• 그리고 예외 발생 시의 CloudVendorNotFoundException 객체를 인자로 받아서 이 메서드의 인수로 매핑되도록 한다.
• 로직 내에서는 예외 정보를 받아서 적절히 처리 후 반환해주어야 하기 때문에, 예외 정보를 담아 보낼 CloudVendorException 객체를 하나 생성한다.
• 인자로 받은 cloudVendorNotFoundException의 message와, cause, 그리고 HttpStatus를 not_found로 하여 생성되도록 한다.

• return 시에는 ResponseEntity에 로직내에서 생성한 cloudVendorException 클래스와 HttpStatus를 인자로 넣어 반환한다.
  
  

• 그리고 이 메서드가 어떤 예외를 처리할 지 알려줘야 하기 때문에, 메서드 위에 @ExceptionHandler라는 어노테이션을 추가해주고, 이는 메서드에 의해 처리될 예외의 목록을 value로 갖는다.
• 즉 CloudVendorNotFoundException이 발생하면 value에 명시되어 있기 때문에, 해당 메서드의 인자로 매핑될 수 있는 것이다. 만약 여러개의 Exception을 한 메서드에서 처리하는 경우, value가 {} 리스트 형태이기 때문에, 쉼표를 하고 여러 개를 추가로 작성해주면 된다.

• 마지막으로 CloudVedorExceptionHandler 클래스에 대해서 @ControllerAdvice 어노테이션을 달아준다
• 이 컨트롤러는 이 프로젝트 전반에 걸쳐서 전역적으로 여러 예외처리를 해야 하기 때문이다.

5. 이제 이러한 예외가 발생할 수 있는 위치로 돌아가서 어떻게 했을 때 예외가 발생하는 지 확인해야 한다.

• 서비스 레이어의 get 메서드에서 오류가 발행하였는데, 로직을 보면 return에서 findId를 호출하도록 되어 있다.
• findId를 통해 반환할 내용이 있다면, cloudVendor에 대한 정보가 출력되겠지만, 찾을 수 없다면 예외를 발생시키고 일반 내부 서버 오류 메시지가 표시된다.
• 따라서 예외 처리 기능을 추가함으로써 출력되는 메시지를 사용자가 오류에 대해 이해하기 쉽게 더 나은 메시지로 표시하고자 한다.
• 예외 처리 기능을 추가해준다.

• if문을 추가하여, findId 호출의 return이 비어있다면 예외를 표시하도록 한다.
  CloudVendorNotFoundException클래스를 throw 문법을 통해 발생시키고, 이때의 message는 오류에 대한 상황 설명을 친숙한 메시지로 제공해준다.
  => "requested cloud vendor does not exist"

6. 실행 결과

• 클라이언트가 제대로 수신한 적절한 오류 응답 404 not found와 함께 적절한 오류 메시지인 cloud vendor를 찾을 수 없다는 메시지가 출력된 것을 확인할 수 있다.

위 과정이 바로 Spring boot rest api 애플리케이션으로 예외 처리를 하는 방식이다.

= 사용자 정의 예외 처리

다음 내용↓↓↓

2023.12.15 - [Web Application/Backend] - [REST API] Spring Boot로 REST API CRUD 간단 구현 (5)-사용자 정의 ResponseEntity

이전 내용↓↓↓

2023.11.11 - [Web Application/Backend] - [REST API] Spring Boot로 REST API CRUD 간단 구현 (2)

DB연동에 이어서, db에 있는 정보를 CRUD 처리해보자.

💡 Model을 entity로 설정

• model인 CloudVendor를 entity로써 하나의 테이블로 선언해주기 위해, CloudVendor 클래스를 수정해준다.

• CloudVendor를 Entity로 선언해주고, Table 이름은 "cloud_vendor_info"로 설정하여 생성 시 이 이름으로 table이 생성된다.
• 이 테이블의 primary key를 vendorId로 설정해주기 위해, vendorId위에 @Id 를 추가해준다.

💡 CloudVendor Repository 생성하기

• CloudVendor Entity에 대한 데이터베이스 작업인 CREATE, READ, UPDATE, DELETE를 수행하기 위해서 JpaRepository 인터페이스를 상속받아(extends) 사용한다.

• 일단 repository 폴더를 생성해주고, 인터페이스로 CloudVendorRepository 파일을 추가한다.

• CloudVendorRepository를 생성할 때, JpaRepository에 Entity이름과, Entity의 pk 데이터타입을 이용해서 define할 수 있다.

💡 CloudVendorService 생성하기

• Service 단에서는 Repository에 접근하여 동작을 수행하도록 한다.

• Service 폴더를 생성하고, CloudVendorService 라는 이름의 인터페이스를 먼저 생성한다.
• 인터페이스를 implements하여 사용한 것이 CloudVendorServiceImpl이다.
• 이렇게 하는 이유는, 인터페이스로 정의해서 서비스 구현체에 직접 의존하지 않고 인터페이스에 의존하게 하여 결합도를 낮추기 위함이다.

public interface CloudVendorService {//인터페이스로 정의해서 서비스 구현체에 직접 의존하지 않고 인터페이스에 의존하게 하여 결합도를 낮춤
    public String createCloudVendor(CloudVendor cloudVendor);
    public String updateCloudVendor(CloudVendor cloudVendor);
    public String deleteCloudVendor(String cloudVendorId);
    public CloudVendor getCloudVendor(String cloudVendorId);
    public List<CloudVendor> getAllCloudVendors();
}

• CloudVendorService 인터페이스이다.
• 구체적인 동작은 없고, 메서드 정의만 해두었다.
• CloudVendor model을 CRUD하는 각각의 메서드이다.
  createCloudVendor : 입력으로 받은 cloudVendor 정보로 CloudVendor를 생성하는 메서드이다.
  updateCloudVendor : 입력으로 받은 cloudVendor 정보로 CloudVendor를 수정하는 메서드이다.
  deleteCloudVendor : 입력으로 받은 특정 cloudVendorId에 대한 CloudVendor 정보를 삭제하는 메서드이다.
  getCloudVendor : 입력으로 받은 특정 cloudVendorId에 대한 CloudVendor 정보를 읽어오는 메서드이다.
  getAllCloudVendor :  모든 CloudVendor 정보를 읽어오는 메서드로, List 형태로 가져온다.

@Service
public class CloudVendorServiceImpl implements CloudVendorService{
    CloudVendorRepository cloudVendorRepository;

    public CloudVendorServiceImpl(CloudVendorRepository cloudVendorRepository) {
        this.cloudVendorRepository = cloudVendorRepository;
    }

    @Override
    public String createCloudVendor(CloudVendor cloudVendor) {
        //more Business logic
        cloudVendorRepository.save(cloudVendor);
        return "Success";
    }

    @Override
    public String updateCloudVendor(CloudVendor cloudVendor) {
        //more Business logic
        cloudVendorRepository.save(cloudVendor);//jpa의 save 메서드의 경우, 이미 있는 값에 대해서는 변경된 내용만 추적해서 수정합니다
        return "Success";
    }

    @Override
    public String deleteCloudVendor(String cloudVendorId) {
        //more Business logic
        cloudVendorRepository.deleteById(cloudVendorId);
        return "Success";
    }

    @Override
    public CloudVendor getCloudVendor(String cloudVendorId) {
        //more Business logic
        return cloudVendorRepository.findById(cloudVendorId).get();
    }

    @Override
    public List<CloudVendor> getAllCloudVendors() {
        //more Business logic
        return cloudVendorRepository.findAll();
    }//이 안에 있는 모든 메서드를 implements 하기 전에는 빨간줄이 떠있음

}

• CloudService를 implements한 것이 CloudVendorServiceImpl이다.
• CloudVendorRepository 객체를 하나 생성하고, repository메서드를 이용해 각 메서드를 동작하도록 한다.
• 처음에 모든 메서드를 implements하기 전에는 빨간 줄이 떠있게 된다. 빨간 표시를 누르면 자동으로 override할 수 있는 틀을 가져오는 버튼이 있다. 이 버튼을 누르면 override해야 할 메서드를 모두 가져와 준다.
• 각 메서드에 맞는 repository의 메서드를 호출하여 데이터베이스 작업이 진행되도록 한다.
• repository의 save() 메서드는 입력받은 Entity 정보를 삽입, 수정한다.
  해당하는 pk가 없었다면 삽입, 이미 있는 pk에 일부 정보만 바뀌었다면 수정 하도록 한다.
• repository의 deleteById() 메서드는 입력받은 Entity의 pk를 통해 해당 정보를 삭제한다.
• repository의  findById() 메서드는 입력받은 Entity의 pk를 통해 해당 정보를 가져온다.
• repository의 findAll() 메서드는 모든 Entity 정보를 가져온다.

💡 CloudVendor Controller 수정하기

• Controller의 CloudVendor Controller를 CloudVendorController로 클래스 이름을 수정한다.
• Controller에서는 서비스 단의 메서드를 호출하여 CRUD를 수행하도록 한다.

public class CloudVendorController {
    CloudVendorService cloudVendorService;

    public CloudVendorController(CloudVendorService cloudVendorService) {
        this.cloudVendorService = cloudVendorService;
    }

    //Read Specific Cloud Vendor Details
    @GetMapping("{vendorId}")
    public CloudVendor getCloudVendorDetails(@PathVariable("vendorId") String vendorId)//위 url 경로로부터 값을 받아와서 사용하므로 어노테이션 추가
    {
        return cloudVendorService.getCloudVendor(vendorId);
    }

    //Read All Cloud Vendor Details
    @GetMapping
    public List<CloudVendor> getCloudVendorDetails()//위 url 경로로부터 값을 받아와서 사용하므로 어노테이션 추가
    {
        return cloudVendorService.getAllCloudVendors();
    }

    //Create Cloud Vendor
    @PostMapping
    public String postCloudVendorDetails(@RequestBody CloudVendor cloudVendor)
    {
        cloudVendorService.createCloudVendor(cloudVendor);
        return "Cloud Vendor Created Successfully";
    }

    //Update Cloud Vendor
    @PutMapping//수정이라 하더라도 특정 id 안받아도됨-> jpa의 save 메서드가 이미 있는 값에 대해서는 변경을 하고, 없으면 삽입을 하는 두가지 역할을 수행하기 때문
    public String updateCloudVendorDetails(@RequestBody CloudVendor cloudVendor)
    {
        cloudVendorService.updateCloudVendor(cloudVendor);
        return "Cloud Vendor Updated Successfully";
    }

    @DeleteMapping("{VendorId}")
    public String deleteCloudVendorDetails(@PathVariable("VendorId") String vendorId)
    {
        cloudVendorService.deleteCloudVendor(vendorId);
        return "Cloud Vendor Deleted Successfully";
    }
}

• CloudVendorService 객체를 하나 생성한다.
• @PathVariable은 url로 받는 값을 메서드의 인자로 받아 사용하기 위한 어노테이션이다.
• @RequestBody는 프론트 단에서 입력한 값을 가져와 메서드의 인자로 받아 사용하기 위한 어노테이션이다.
• 각각의 CRUD 메서드에 맞는 Service 단의 메서드를 호출하여 수행한다.

💡 실행 결과

• 첫 실행 후에는, 데이터 베이스에 Cloud Vendor Entity에 대한 테이블이 처음 생성되므로, 해당 테이블의 레코드는 Empty set 상태임을 확인할 수 있다.
• POST MAN을 사용하여 정보를 입력한다.
• post 모드에서 C1-C5  총 5개의 레코드를 삽입한다.

• 실행 결과, 잘 삽입되었다는 메시지가 출력된다

Cloud Vendor Created Successfully

• GET 모드에서 C3에 대한 값을 가져온다.

•  실행 결과 C3에 대한 모델 값이 잘 반환된다.
  
  
• GET 모드에서 모든 모델 값을 가져온다.

• 실행 결과 모든 모델 값이 잘 반환된다.
• PUT 모드에서 C4에 대한 모델 값을 address를 London으로 변경해본다.

• 실행 결과 잘 update되었다는 메시지가 출력된다.

Cloud Vendor Updated Successfully

• 그리고 GET 모드를 통해 검색한 결과, 변경된 값이 잘 반영된 것을 확인할 수 있다.
  
  
• DELETE 모드를 통해 C3를 삭제해본다.

• 실행 결과 잘 삭제되었다는 메시지가 출력된다.

Cloud Vendor Deleted Successfully

• GET 모드에서 C3를 읽어들이려고 하니, 예외처리를 하지 않아 에러가 발생한다. 없는 값을 읽으려고 해서 발생하는 오류이다.
  
  

• 이로써 모든 CRUD가 잘 동작하는 것을 확인하였다.
• 실시간으로 powershell을 통해 db 상태를 확인하며 잘 동작하는 것도 확인하였다.

다음시간에는 예외처리를 위한 코드를 추가할 예정이다.

다음 내용↓↓↓

2023.11.22 - [Web Application/Backend] - [REST API] Spring Boot로 REST API CRUD 간단 구현 (4)-예외처리/handle Exception