Bean Validation이란? Bean Validation이란 어노테이션을 통해 자바 빈(Java Bean)의 유효성을 검증할 수 있는 기술 표준(JSR380)이다. 어노테이션을 사용하여 유효성 검사 규칙을 정의할 수 있어 사용하기 편리하다. 아래와 같이 자바 빈 클래스의 필드나 메서드에 특정 어노테이션을 적용해 유효성 검사를 수행할 수 있다. @Email private String email; @NotNull private Long id; @Email public String getEmail(){ return email; } 예를 들어 @Email 어노테이션으로 해당 필드에 이메일 형식의 값이 들어오는지, @NotNull 어노테이션을 통해 Null 값을 검사할 수 있다. 이러한 Bean Valida..
OpenFeign 이란? OpenFeign은 선언적인(Declarative) HTTP Client 혹은 REST Client이다. FeignClient로 선언된 인터페이스를 구현하고 어노테이션을 달아주는 것만으로 HTTP Client 서비스를 작성할 수 있다. 이러한 OpenFeign은 Netflix에서 Netflix OSS 프로젝트의 일환으로 개발했다. 이후 오픈소스 커뮤니티로 옮겨졌고 현재는 스프링 클라우드(Spring Cloud) 생태계에 통합되어 Spring Cloud OpenFeign으로 사용 가능하다. OpenFeign vs RestTemplate 만약 다른 외부 날씨 API를 호출하려고 할 때 RestTemplate을 활용하면 아래와 같이 코드를 작성할 수 있다. @Service public..
Bean Validation API를 개발하다 보면 DTO에 들어오는 값을 검증해야 할 때가 있다. 예를 들어 이름은 공백이면 안된다던지, 휴대폰 번호는 null이 아니 여야 한다는 등의 조건들이 있을 것이다. 이러한 검증은 Jakarta Bean Validation에서 제공하는 @NotNull @NotBlank, @NotEmpty 등의 어노테이션을 활용하면 간단하다. 어노테이션을 적용하지 않을 경우 @PostMapping(...) public ResponseEntity buy(@RequestBody BuyRequestDto buyRequestDto){ if(buyRequestDto.getName() == null){ return new ResponseEntity("Error", HttpStatus.BA..
프론트 컨트롤러(Front Controller) 디스패처 서블릿에 대해 알기 위해선 프론트 컨트롤러(Front Controller)에 대해 알아야 한다. 프론트 컨트롤러는 말 그대로 모든 컨트롤러 앞에 있는 컨트롤러이다. 클라이언트의 모든 요청을 앞에서 받고 해당 요청을 처리할 적절한 컨트롤러를 결정한다. 예를 들어 사용자가 로그인을 하려고 하면 해당 요청을 프론트 컨트롤러가 받아 로그인 컨트롤러에게 넘길 것이다. 만약 사용자가 구매 요청을 보낸다면 프론트 컨트롤러는 구매 컨트롤러를 호출할 것이다. 프론트 컨트롤러의 필요성 프론트 컨트롤러를 사용하지 않고 클라이언트의 요청을 일일히 적절한 컨트롤러에 매핑시켜놓으면 어떨까? 이것은 매우 비효율적이다. 웹 서비스를 구현하다보면 필연적으로 공통 기능이 필요하기..
@PathVariable 스프링에서 @PathVariable 어노테이션을 사용하면 URI의 템플릿 변수를 메서드 파라미터에 바인딩할 수 있다. 예를 들어 https://code-lab1.tistory.com/{idx} 위의 {idx}는 URI 템플릿 변수(이하 템플릿 변수)로 값이 바뀌는 가변형 변수이다. 실제로는 https://code-lab1.tistory.com/127 위와 같이 실제 값이 들어가게 된다. 이처럼 REST API로 전송되는 템플릿 변수를 메서드의 파라미터에 바인딩할 수 있다. value 속성 @RestController public class SomethingController{ @GetMapping("/student/{name}") public ResponseEntity getSt..
에러 상황 @FeignClient public interface SomeApi{ @PostMapping("/my/test", consumes = MediaType.MULTIPART_FORM_DATA_VALUE) void postSomthing( @RequestPart MultipartFile uploadFiles, @RequestPart MyDto myDto ); } 상황은 위와 같이 Multipart/form-data를 MultipartFile 하나와 내가 정의한 Dto 하나를 파라미터로 전송하는 것이였다. 구글링을 통해 @RequestBody나 @RequestParam 대신 @RequestPart를 사용하면 된다는 정보를 얻고 위와 같이 코드를 작성하였다. 그런데 아래와 같은 에러가 발생했다. "Re..
No Mapping for GET 에러 No Mapping for GET 에러는 GET 요청에 대응하는 URL을 매핑할 수 없을 때 발생한다. 이때 다음과 같은 방법들을 시도해 오류를 해결할 수 있다. 1. URL 오타 확인 Controller에서 @RequestMapping(value = "...") 혹은 GetMapping(value = "...") 등에서 value 값에 제대로 된 URL을 입력했는지 확인해보자. 오타가 있다면 제대로 정정하자. 2. @Controller 어노테이션 확인 오류가 난 메서드가 위치한 Controller 클래스에 @Controller 어노테이션을 붙였는지 확인해보자. 어노테이션을 붙이지 않으면 해당 클래스가 컨트롤러 클래스인것을 스프링이 인식하지 못한다. 3. 기본 패키..
컴포넌트 스캔(Component Scan) 컴포넌트 스캔이란 스프링이 스프링 빈(Bean)으로 등록될 준비가 된 클래스들을 스캔하여 빈(Bean)으로 등록해주는 과정을 말한다. @Component 어노테이션이 붙어있는 클래스들은 전부 컴포넌트 스캔의 대상이 된다. @Configuration, @Service, @Repository, @Controller, 등의 어노테이션에도 전부 @Component이 포함되어 있어 자동으로 컴포넌트 스캔의 대상이 된다. @ComponentScan과 컴포넌트 스캔 범위 컴포넌트 스캔을 사용하기 위해서는 설정 정보 클래스에 @ComponentScan 어노테이션을 붙여줘야 한다. 이때 컴포넌트 스캔의 범위는 설정 정보 클래스의 패키지를 포함한 모든 하위 패키지가 된다. 이때 ..
싱글톤 패턴이란? 만약 스프링이 없는 순수한 DI 컨테이너 Appconfig에 고객들이 요청을 보낸다고 하자. DI 컨테이너는 요청을 받을 때마다 객체를 새로 생성할 것이다. 따라서 고객 트래픽이 초당 100건이 나오면 초당 100개의 객체가 생성되고 소멸된다. 이는 메모리 낭비가 매우 심하다. 해결 방안으로는 객체를 딱 1개만 생성하고 이를 공유하도록 설계하면 된다. 이것이 바로 싱글톤 패턴이다. 즉, 싱글톤 패턴이란 클래스의 인스턴스가 딱 1개만 생성되는 것을 보장하는 디자인 패턴이다. 따라서 객체 인스턴스를 2개 이상 생성하지 못하도록 막아야 한다. public class SingletonService { //1. static 영역에 객체를 딱 1개만 생성해둔다. private static fina..