이번에 mac을 8버전에서 16으로 업데이트할 일이 생겼다. 근데 mac 초심자라 윈도우에서는 잘 되어있는 GUI 덕에 편하게 자바 버전을 바꿀 수 있었지만 mac환경에서는 터미널에서 구동해야하기에 확 와닿지도 않고 폴더의 트리구조도 머릿속에 잘 안 그려졌다.그래서 이

Servlet 앞서 Web server에 대해 공부할 때 그런데 비즈니스 로직을 제외한 나머지 기능을 모든 res마다 구현하는 것은 미친짓이라고 하였다. 그리고 개발자가 이를 생략할 수 있도록 도와준 것이 바로 Servlet이라 하였다. 보면 위가 서블릿 코드인데

아니 gif 왜 깨지는건데~ 개억울하잖슴~대충 아래 사진과 같다 사실 저 체크박스를(모양은 토글이지만 넘어가자) 정확히 aim하여 클릭하기란 정말 어려운 일이다.그래서 대충 id나 이름이나 여타 다른 컬럼을 클릭해도 체크박스가 활성화되도록 만들고싶었다.방법은 매우 간단

우선 캐시가 없을 때 상황을 가정해보자.사용자가 서버에 1.1M의 이미지를 요청하고 받았는데 또 요청하면 또 1.1M의 이미지를 다운받아야한다. 이는 사용자로 하여금데이터가 변경되지 않았음에도 계속 네트워크를 통해서 데이터를 다운받야아한다.인터넷 네트워크는 매우 느리고

클라이언트가 서버에서 받은 쿠키를 저장하고, HTTP 요청시 서버로 전달그럼 왜 전달할까? -> HTTP는 기본적으로 무상태 프로토콜이기 때문이다.클라이언트와 서버가 요청과 응답을 주고 받으면 연결이 끊어진다.클라이언트가 다시 요청하면 서버는 이전 요청을 기억하지 못

HTTP 헤더 RFC2616(과거-폐기) 헤더 분류 General header: 메시지 전체에 적용되는 정보, Connection close Request header: 요청 정보, User-Agent: Mozilla/5.0 | Macintosh; Resp

HTTP API 설계 예시 HTTP API - collection 위 사진처럼 GET에 뭐 정렬조건, 검색조건 등 파라미터를 넣어서 처리하도록 설계하면 된다.. 이 memebers의 리소스에 대한 HTTP method의 모음을 collection이라 한다.

클라이언트에서 서버로 따로 파라미터를 전송할게 없다. 그냥 리소스 경로로 단순하게 조회가 가능하다.통상 이미지, 정적 텍스트 문서를 사용하며 GET method를 사용한다.클라이언트에서 쿼리 파라미터를 사용하여 서버에서 쿼리파라미터를 기반으로 정렬 필터를 하여 결과를

URI설계는 바로 리소스 식별이다.이 리소스 식별이 뭘까?리소스는 어떠한 행위, 동작이 아닌 개념이다. 예를들어 회원을 "등록, 수정, 조회"하는게 리소스가 아니라"회원"이라는 개념이 리소스이다.그럼 이 "회원" 리소스를 식별하여 URI에 매핑하면 된다.그리고 이 리소

HTTP란? Hypertext Transfer Protocol Hypertext html: 문서 간의 링크를 통해서 연결할 수 있는 HyperText 문서를 통해서연결할 수 있는 html을 전송하는 프로토콜로 시작이 되었다. 그런데 지금은 모든 것을 HTTP prot

리소스를 식별하는 통합된 방법URL, URI, URN 다 들어본 놈 들인데URI는 URL(Locator) 과 URN(Name) 또는 둘다 추가로 분류될 수 있다.표준 스펙 찾기 -> 1.1.3대강 정리하자면 리소스의 실제 위치는 URL에 있고 리소스의 이름은 URN이다

만약 두 pc가 있다고 가정하자. 이 두 pc가 1m 내외에 있다면 그냥 케이블을 연결하면 되겠지만, 두 pc가 대륙을 건너 있다면 인터넷 망을 통해서 보내야할 것이다.그런데 인터넷 망이 보기보다 복잡하다 해저케이블일 수도 있고 인공위성 통신이 될 수도 있고 굉장히

적용 대상이 클래스면 TARGET_CLASS를 인터페이스면 INTERFACES를 선택해주면 된다.이렇게 하면 MyLogger 클래스의 가짜 클래스(프록시)를 만들어두고 HTTP req와 상관없이 가짜 프록시 클래스를 다른 빈에 미리 주입해 둘 수 있다.위 Scope 어

웹 스코프 웹 스코프의 특징 웹 스코프는 웹 환경에서만 동작한다. 웹 스코프는 프로토타입과 다르게 스프링이 해당 스코프의 종료시점까지 관리한다. 따라서 종료 메서드가 호출된다. 웹 스코프의 종류 request : HTTP 요청 하나가 들어오고 나갈 때 까지 유지되는

스프링 컨테이너에 프로토타입 스코프의 빈을 요청하면 항상 새로운 객체 인스턴스를 생성해서 반환한다. 하지만 싱글톤 빈과 함께 사용할 때는 의도한 대로 잘 동작하지 않으므로 주의해야한다. 1-1. 클라이언트 A는 스프링 컨테이너에 프로토타입 빈을 요청한다.2-1. 스프링

빈 스코프란? 지금까지 우리는 스프링 빈이 스프링 컨테이너의 시작과 함게 생성되어 스프링 컨테이너가 종료될 때 까지 유지된다고 학습했다. 이것은 스프링 빈이 기본적으로 싱글톤 스코프로 생성되기 때문이다. 스코프는 말 그대로 빈이 존재할 수 있는 범위를 뜻한다. 스프링

빈 생명주기 콜백 시작 DB connection pool이나 네트워크 소켓처럼 어플리케이션 시작 시점에 필요한 연결을 뭐 대강 10개면 10개 100개면 100개를 미리 해두고, 왜냐하면 TCP/IP 핸드쉐이킹하고 연결하는데 조금 시간이 걸리기 때문이고 또 연결해둔 걸

왜냐하면 스프링은 @Component, @Controller, @Service, @Repository 처럼 계층에 맞추어 일반적인 어플리케이션 로직을 자동으로 스캔할 수 있도록 지원하게 발전하고 있다.또 boot는 컴포넌트 스캔을 기본으로 사용하고 부트의 다양한 스프링

의도적으로 정말 해당 타입의 스프링 빈이 다 필요한 경우도 있다.예를들어 할인 서비스를 제공하는데, 클라이언트가 할인의 종류(rate, fix)를 선택할 수 있다고 가정할 때 스프링을 사용하면 소위말하는 전략 패턴을 매우 간단하게 구현할 수 있다.위 코드중 대부분은 앞

앞서 학습한 @Qualifier라는 좋은 빈 판독기를 알아보았다. 하지만 이 어노테이션의 단점은 컴파일시 타입체크가 안 된다. -> 그래서 어노테이션을 집적 만들어서 문제를 해결할 수 있다.우선 프로젝트.프로젝트명 밑에 이름은 annotation이라 하여 package