서블릿으로 개발할 때는 뷰(View)화면을 위한 HTML을 만드는 작업이 자바 코드에 섞여서 지저분하고 복잡했다.

WAS를 실행하면 HttpServletRequest와 HttpservletResponse를 구현해준다. request를 통해 요청하고 response를 통해 응답할 수 있다. HttpServletRequest 역할 서블릿은 개발자가 HTTP 요청 메시지를 편리하게

HTTP 기반으로 동작정적 리소스 제공, 기타 부가기능정적(파일) HTML, CSS, JS, 이미지, 영상예) NGINX, APACHEHTTP 기반으로 동작웹 서버 기능 포함+ (정적 리소스 제공 가능)프로그램 코드를 실행해서 애플리케이션 로직 수행동적 HTML, HT

캐시 기본동작 > 캐시가 없으면 > * 데이터가 변경되지 않아도 계속 네트워크를 통해서 데이터를 다운로드 받아야 한다. > * 인터넷 네트워크는 매우 느리고 비싸다. > * 브라우저 로딩 속도가 느리다. > * 느린 사용자 경험 캐시 적용시 캐시 덕분에 캐시 가능 시

HTTP 헤더 HTTP 전송에 필요한 모든 부가정보를 담고있다. 예) 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트, 서버 정보, 캐 시 관리 정보... 표준 헤더가 너무 많음 https://en.wikipedia.org/wiki/L

상태코드 클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능 1xx (Informational): 요청이 수신되어 처리중 2xx (Successful): 요청 정상 처리 3xx (Redirection): 요청을 완료하려면 추가 행동이 필요 4xx (Client

데이터 전송 클라이언트에서 서버로 데이터 전송 방법 쿼리 파라미터를 통한 데이터 전송 GET 주로 정렬 필터(검색어) 메시지 바디를 통한 데이터 전송 POST, PUT, PATCH 회원 가입, 상품 주문, 리소스 등록, 리소스 변경 4가지 상황 1. 정적 데이터 조회

API URI 설계 URI 설계에서 가장 중요한 것은 리소스 식별 이다. 리소스란? 회원을 등록하고 수정하고 조회하는게 아니라 회원이라는 개념 자체가 바로 리소스다. 리소스 식별 방법? 회원을 등록하고 수정하고 조회하는 것을 모두 배제 회원이라는 리소스만 식

특징 3. HTTP 메시지 위 사진의 요청메시지 기준 > GET /search?q=hello&hl=ko HTTP/1.1 > Host: www.google.com 요청메시지 HTTP 메서드 (GET) 종류 : GET, POST, PUT, DELETE...

HyperText Transfer Protocol HTTP 메시지에 모든 것을 전송 • HTML, TEXT • IMAGE, 음성, 영상, 파일 • JSON, XML (API) • 거의 모든 형태의 데이터 전송 가능 • 서버간에 데이터를 주고 받을 때도 대부분 HTTP

URI - Uniform Resource Identifier Uniform: 리소스 식별하는 통일된 방식 Resource: 자원, URI로 식별할 수 있는 모든 것(제한 없음) Identifier: 다른 항목과 구분하는데 필요한 정보 URL, URN URL - Loc

지난번 proxy 정리 글에서 나왔던 LazyInitializationException에 대해 정리하려고 한다. > LazyInitializationException 는 영속성 컨텍스트에 있던 Entity가 준영속(Detached)상태가 되었을때 Lazy Loadin

지난번 유튜브 네트워크 강의를 들으며 정리했던 내용이지만 좀더 자세하게 정리된 내용을 보면서 다시 공부했다.지정한 IP 주소에 데이터 전달하는 역할을 한다.전달할때 패킷(Packet)이라는 통신단위로 데이터를 전달한다. 한계비연결성패킷을 받을 대상이 없거나 서비스 불

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

싱글톤 빈과 함께 사용시 문제점 스프링 컨테이너에 프로토타입 빈 직접 요청1 클라이언트A는 스프링 컨테이너에 프로토타입 빈을 요청한다. 스프링 컨테이너는 프로토타입 빈을 새로 생성해서 반환(x01)한다. 해당 빈의 count 필드 값은 0이다. 클라이언트는 조회한 프

빈 스코프란? 빈이 존재할 수 있는 범위를 말한다. 스프링이 지원하는 스코프는 다음과 같다. 싱글톤: 기본 스코프, 스프링 컨테이너의 시작과 종료까지 유지되는 가장 넓은 범위의 스코프이다. 프로토타입: 스프링 컨테이너는 프로토타입 빈의 생성과 의존관계 주입까지만 관여하

생명주기 콜백

생성자 주입을 선택하는 이유 1. 불변 대부분의 의존관계 주입은 한번 일어나면 애플리케이션 종료시점까지 의존관계를 변경할 일이 없다. 오히려 대부분의 의존관계는 애플리케이션 종료 전까지 변하면 안된다.(불변해야 한다.) 수정자 주입을 사용하면, setXxx 메서드를 p

의존관계 주입 의존관계 주입은 크게 4가지 방법이 있다. 생성자 주입 수정자 주입(setter 주입) 필드 주입 일반 메서드 주입 1. 생성자 주입 이름 그대로 생성자를 통해서 의존 관계를 주입 받는 방법이다. 특징 생성자 호출 시점에 딱 1번만 호출되는것이 보장

ComponentScan 지금까지 스프링 빈을 등록할 때는 자바 코드의 @Bean이나 XML의 &ltbean&gt 등을 통해서 설정 정보에 직접 등록할 스프링 빈을 나열했다. 지금까지 예제에서는 몇개가 안되었지만, 이렇게 등록해야 할 스프링 빈이 수십, 수백개가 되면