필터(Filter)란? 필터(Filter)는 서블릿(Servlet)에 도달하는 요청(Request)이나 서블릿에서 클라이언트에게 보내는 응답(Response)을 중간에 조작하거나 막을 수 있는 JAVA 진영의 기술이다. Filter는 Spring MVC에 종속되지 않아 스프링 환경이 아닌 다른 환경에서도 사용가능하다. 예를 들어 Spring Security는 Filter를 이용한 Authentication 및 Authorization 기술이다. Spring Security를 사용하면 모든 요청과 응답을 중간에서 검증할 수 있다. 이러한 이유로 Spring Security는 Spring MVC 환경이 아닌 곳에서도 사용할 수 있다. Filter Chain 필터는 체인으로 구성될 수 있고 중간에 필터를 자유..
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..
메시지(Message) 기능 실무를 진행하다 보면 무언가의 이름이 바뀌는 건 심심치 않게 발생한다. 예를 들어 아주 사소하지만 "상품명"이라는 단어를 "상품이름"으로 바꾸라는 지시가 내려왔다고 하자. 만약 화면 수가 수십개가 넘어가는데 일일이 모든 단어를 수정하는 것은 귀찮고 비효율적일 것이다. 스프링은 이러한 다양한 메시지를 한 곳에서 관리할수 있는 메시지(Message) 기능을 제공한다. 예를 들어 아래와 같이 messages.properties 라는 메시지 관리 파일을 만들어 관리할 수 있다. item.itemName=상품명 item.price=가격 item.quantity=수량 ... 이렇게 메시지를 관리하면 상품명을 화면에서 사용할 때 "상품명"으로 하드코딩하지 않고 "item.itemName"..
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..
Tests 포스트맨의 Tests 탭에 작성한 Test Script는 Request에 대한 Response가 도착한 뒤 실행된다. Pre-request Script가 Request가 전송되기 전에 실행되는 것과 상반된다. 보통 Tests 스크립트는 요청에 대한 응답이 올바르게 왔는지, 의도한 결과대로 응답이 왔는지, 응답의 내용을 확인할 때 유 용하게 사용할 수 있다. + 참고) [Postman] 포스트맨 pre-request script 활용법, token 갱신 자동화 Pre-request script 포스트맨에서 pre-request script는 request를 전송하기 전에 자바스크립트 코드를 실행할 수 있는 기능이다. pre-request script는 단순히 request 뿐만 아니라 colle..
Pre-request script 포스트맨에서 pre-request script는 request를 전송하기 전에 자바스크립트 코드를 실행할 수 있는 기능이다. pre-request script는 단순히 request 뿐만 아니라 collection, folder 단위로도 작성이 가능하다. pre-request script는 주로 환경 변수 설정, 파라마티나 헤더 설정, 디버깅 코드 실행 등으로 사용이 가능하다. 또는 로그를 남기는 용도로도 사용할 수 있다. Tests와의 차이는 Tests는 request가 전송되고 response가 온 후에 실행되지만, pre-request script는 request가 전송되기 전에 실행된다는 점이다. 참고) [Postman] 포스트맨 환경변수(Environments ..
포스트맨 환경(Environments) 설정 포스트맨은 한 개 이상의 변수들(variables)을 저장해놓을 수 있는 환경(Environments)을 설정할 수 있다. 사이드바의 Environments 탭에서 + 버튼을 누르면 새로운 환경을 만들 수 있다. 예를 들어 [그림 2]와 같이 개발(dev), 운영(prod)환경을 따로 구성할 수 있다. 이렇게 환경을 설정해두고 해당 환경에 여러 변수들을 저장해놓으면 환경이 바뀔때마다 일일히 변수값을 변경해주지 않아도 된다. 오른쪽 위 화면에서 본인이 원하는 환경을 선택할 수 있다. 환경변수(Environments Variables) 설정 환경을 선택하면 해당 환경에 환경변수들을 설정할 수 있다. 예를 들어 호출하고 싶은 도메인 주소를 저장할 host라는 변수를..