GO CAN DO IT

더이상 미룰 수 없다. 너의 결혼, 나의 Rest API와 Hateoas 정리 ㅋ_ㅋ Rest, Restful 참 많이도 들어봤다. 도대체 Rest API는 무엇인가? 결론적으로 얘기하면 REST는 아키텍쳐이고, REST API는 REST를 기반으로 서비스 API를 구현 한 것이다. REST Rest란? 먼저 REST는, 자원 기반의 구조(ROA, Resource Oriented Architecture)설계에서 그 중심에 Resource가 있고 이 Resource 를 처리 하기 위해서 HTTP Method를 활용하는 아키텍쳐이다. REST에서 가장 중요한 것은 Resource이다. 이렇게 중요한 자원을 REST에서는 서버와 클라이언트간에 어떻게 주고 받느냔 말이다? 그 답은 바로 REST 안에 있다. R..

1. 메소드 Argument와 Return Type : 주로 요청 그 자체 또는 요청에 들어있는 정보를 받아오는데 사용한다. https://docs.spring.io/spring-framework/docs/current/reference/html/web.html#mvc-ann-arguments Web on Servlet Stack Spring Web MVC is the original web framework built on the Servlet API and has been included in the Spring Framework from the very beginning. The formal name, “Spring Web MVC,” comes from the name of its source mo..

ApplicationContext는 Bean Factory의 역할 + Spring의 여러가지 기능들을 담당하고 있다. 이 ApplicationContext는 다음과 같은 인터페이스들을 상속받고 있는데 ApplicationEventPublisher EnvironmentCapable HierarchicalBeanFactory ListableBeanFactory MessageSource ResourceLoader ResourcePatternResolver 이들 중 가장 먼저 살펴볼 것은, EnvionmentCapable 인터페이스이다. 이 Environment가 제공하는 기능은 크게 프로파일과 프로퍼티로 나눌 수 있는데, 먼저 프로파일에 대해 알아보자. 1. 프로파일 인터페이스 이 프로파일은 개발/ 운영서버가..

Bean의 Scope는 기본적으로 싱글톤이다. 프로그램 구동시 Bean의 인스턴스는 오직 하나라는 뜻이다. Bean이 가질수 있는 Scope 는 싱글톤 외에 매번 인스턴스를 새로 생성하는 ProtoType 도 있다. 만약, 프로토 타입 빈이 싱글톤 빈을 참조하면 어떻게 될까? 매번 프로토타입의 빈은 새로운 인스턴스로 생성되고, 그 인스턴스들이 바라보는 싱글톤 빈은 동일한 인스턴스일 것이다. 이럴 때는 아무런 문제가 되지 않는다. 그렇다면, 싱글톤 빈이 프로토 타입 빈을 참조하면 어떻게 될까? 싱글톤이 생성 된 이후에 프로토타입 빈이 변경이 되어도 해당 내용이 업데이트가 되지 않는다. 이를 업데이트하려면 Scoped-proxy값을 설정해주거나, 참조시 참조 객체를 Object-Provider 리스트로 감싸..

여기 BookRepository 객체와, BookRepository 객체를 사용하는 BookService 객체가 있다고 가정해보자. 그리고 이 BookService 객체에서 BookRepository 객체를 주입받아야 하는 상황에서 BookService는 Bean으로 등록을 해주고, BookRepository 는 Bean으로 등록을 하지 않았다고 해보자. // #1. BookService @Service public class BookService { BookRepository bookrepository; @Autowired public void BookService(BookRepository bookRepository){ this.bookRepository = bookRepository; } } // ..

#스프링 IoC 토비의 스프링에서 먼저 공부한 스프링 IoC에 대해 다시 한번 리마인드를 해보자. First, IoC stands for Inversion Of Control 즉 제어의 역전이라는 뜻이다. 스프링 프레임워크 안에서의 객체들은 자신들이 사용할 객체들을 스스로 생성하지도 않고, 자기 자신들도 어디서 사용되는지 알 수가 없다. 오브젝트들의 생성과 책임에 대한 제어가 오브젝트 스스로에게 있지 않고, 이 권한을 위임한 다른 특별한 오브젝트에게 있다! 오브젝트의 입장에서는 그 특별한 오브젝트로부터 생성과 책임에 대해 제어를 받으니 control의 방향이 inversed 된 것이다. 그리고 이러한 IoC방식에서 말하는 특별한 Object를 Application Context, 제어권이 없는 오브젝트들..