오늘의하루

주제 선정 수많은 주식 관련 API가 있지만 국내 상장 ETF에는 숨은 수수료를 알려주는 API는 아직 보지 못했다. 그래서 이번 미니 프로젝트의 주제는 국내 상장 ETF의 진짜 수수료를 알려주는 API 서버를 만들어 보려고한다. 자료 수집 우선 ETF의 정보를 알기 위해서 금융 투자 협회라는 사이트를 방문하였고 여기서 모든 ETF의 수수료를 확인할 수 있었다. 쉽게 여기서 제공 하는 API를 사용해서 자료를 받으려고 했지만 API가 없어서 자동화 수집을 하기로 생각했다. 필수 기능 API Service Key 발급 기능 - 메일 주소, 사용 목적, 닉네임등을 입력받은 후 Service key 발급 - 권한의 경우 관리자를 제외한 모든 사용자는 "NOMAL"이라는 권한을 준다. - 인증 / 인가의 경우 ..

Spring의 Service에 대하여... 핵심 비즈니스 로직이 들어있는 계층이다. 비즈니스 로직은 UI와 데이터 저장 기술이 변경되도 최대한 변경없이 유지되어야 하기 때문에 가급적 특정 구현 기술에 의존하지 않고 순수하게 유지하는 것이 좋다. 데이터 액세스 계층에서 Checked Exception을 UnChecked Exception으로 바꾸는 이유가 여기있다. Service에서는 특정 구현 기술에 의존하지 않아야 때문에 데이터 액세스 계층에서 발생하는 예외인 SQLException같은 Checked Exception이 Service 계층까지 넘어오는 것을 방지하는 것 입니다. 또한 Spring에서는 기본적으로 Uncheck Exception의 경우 트랜젝션을 rollback해주는 것을 Default값..

기본적으로 BasicErrorController는 기본적인 로직이 모두 개발되어 있다. 개발자는 룰과 우선순위에 따라서 등록만 하면된다 저장 위치 정적 HTML은 정적 리소스(resources/static/error/xx) 동적으로 오류화면을 만들땐 뷰 템플릿(resources/templates/error/xx) BasicErrorController의 처리 순서 뷰 템플릿에서 찾는다. 정적 리소스(static / public) 적용 대상이 없을때 뷰 이름 (error) - default default 오류 뷰의 위치는 resources/templates/error.html이다. 그외 기본적으로 명확한 이름 우선적으로 찾는다. 예시) 500.html, 5xx.html, 404.html이 있다면 500과40..

Exception 요청 > WAS > 필터 > 서블릿 > 인터셉터 > 컨트롤러(예외발생) > 인터셉터 > 서블릿 > 필터 > WAS 서버 내부에서 처리할 수 없는 오류가 발생했다고 생각하여 Http 상태코드 500 반환 response.sendError(Http 상태코드, 오류메시지) 요청 > WAS > 필터 > 서블릿 > 인터셉터 > 컨트롤러(sendError()) > 인터셉터 > 서블릿 > 필터 > WAS(sendError 호출 기록 확인 / 지정된 URL로 다시 요청) > (필터) > 서블릿 > 인터셉터 > 컨트롤러 > 뷰 sendError를 호출하면 response내부에는 오류가 발생했다는 상태를 저장한다. 서블릿 컨테이너는 응답하기 전에 response에 sendError가 호출되었는지 확인한다..

필터 : Servlet 흐름 : HTTP 요청 > WAS > 필터 > 디스패처 서블릿 > 컨트롤러 인터셉터 : SpringMVC 흐름 : HTTP 요청 > WAS > 필터 > 디스패처 서블릿 > 스프링 인터셉터 > 컨트롤러 참고 : 필터와 인터셉터는 두가지 모두다 체인이 가능하다. 체인이란? 여러개를 사용할 수 있다는 것이다. 예시1) HTTP 요청 > WAS > 필터1 > 필터2 > 필터3 > 디스패처 서블릿 > 컨트롤러 예시2) HTTP 요청 > WAS > 필터 > 디스패처 서블릿 > 인터셉터1 > 인터셉터2 > 인터셉터3 > 컨트롤러 인터셉터 간단히 알아보기 참고 : 인터셉터는 싱글톤으로 관리되기 때문에 지역변수의 사용을 유의해야한다. preHandle 핸들러 어댑터를 호출하기 전에 실행된다. 반환..

@ModelAttribute 필드 단위로 적용되며 특정 타입이 맞지 않는 오류가 발생해도 나머지 필드는 정상적으로 처리된다. @RequestBody HttpMessageConverter는 객체 단위로 적용되기 때문에 하나라도 잘못된 타입이 들어오면 예외가 발생한다. 정리 @ModelAttribute는 필드 단위로 바인딩이 적용되며 특정 필드가 바인딩 되지 않다고 나머지 필드는 정상적으로 바인딩 되고 @Validated를 통해 Validator를 사용한 검증이 적용된다. @RequestBody는 HttpMessageConverter 단계에서 JSON 데이터를 객체로 변경하지 못하면 예외가 발생하기 때문에 Controller가 호출되지 못하고 이로 인해 @Validated를 통한 Validator를 사용한 ..

Spring 구조 1. 클라이언트 요청 2. DispatcherServlet (Front Controller 패턴) 3. DispatcherServlet이 Handler Mapping (핸들러 조회) 4. 해당 Handler를 처리할 수 있는 Handler Adapter 조회 5. 있다면 DispatcherServlet에서 HandlerAdapter 생성 6. Handler Adapter에서 Handler(Controller) 호출 7. Handler(Controller) 수행 후 HandlerAdapter에게 반환 8. Handler Adapter는 ModelAndView를 DispatcherServlet에게 반환 9. DispatcherServlet은 ViewResolver 호출하여 View를 반환 ..

웹서버 (Web Server) HTTP 기반으로 동작 "정적 리소스 제공", 기타 부가기능 정적(파일) HTML, CSS, JavaScript, 이미지, 영상 예) NGINX, APACHE 웹 애플리케이션 서버 (WAS - Web Application Server) HTTP 기반으로 동작 웹 서버 기능 포함 + 정적 리소스 제공 가능 프로그램 코드를 실행해서 "애플리케이션 로직 수행" 동적 HTML, HTTP API (JSON) 서블릿, JSP, 스프링 MVC 예) 톰캣, Jetty, Undertow 기본 웹 시스템 구성 - WAS + DB 단점 WAS가 너무 많은 역할을 담당하기 때문에 서버 과부하 우려된다. WAS는 쉽게 죽는다. 중요한 애플리케이션 로직이 정적 리소스때문에 수행이 어려울 수 있다. ..

request 웹 요청이 들어오고 나갈때까지 유지 되는 스코프 클라이언트 A가 요청하면 A전용 객체가 만들어지고 서비스에서 A 객체를 조회할 수있으며 응답으로 요청이 종료되면 해당 스코프의 객체는 소멸한다. Prototype은 매번 새로운 객체를 만들지만 request는 요청이 들어오면 생성하고 응답하기 전까지 유지된다. Prototype은 소멸전 콜백이 안되지만 request의 경우 소멸전 콜백이 가능하다. 문제. 서버 실행시에는 요청이 없기 때문에 request scope의 빈을 주입받을 수 없다. 만약 의존관계 주입시 request scope의 빈을 주입한다고 가정했을때 어떻게 해결할 수 있을까? ObjectProvider를 이용하여 빈의 생성을 지연 시킬 수 있다. @Component @Scope..

Bean Scope Bean이 존재할 수 있는 범위를 뜻한다. Singleton Bean의 기본 스코프이며 스프링 컨테이너의 시작부터 종료까지 유지되는 가장 넓은 범위의 스코프이다. Prototype 스프링 컨태이너는 Prototype Bean의 생성과 의존관계 주입까지만 관여하고 더는 관리하지 않고 반환하는 가장 짧은 범위의 스코프이다. 초기화 콜백까지는 불러주지만 소멸전 콜백은 해주지 않는다. 종료 메서드의 경우 직접 호출해야한다. 만약 Singleton내부에서 Prototype을 사용하려면? 이 질문의 의도는 여러명의 클라이언트가 요청을 보낼때 마다 Prototype을 새롭게 만들어서 주입이 가능하냐는 말이다. 만약 기존에 의존관계를 주입하듯이 하면 처음 주입 받은 Prototype이 Singlet..