서블릿은 request를 받아서 response를 만드는 구조이다.
즉 서블릿 코드의 핵심은 결국 두 객체로 귀결된다.
- HttpServletRequest : 브라우저가 보낸 요청을 “읽는” 객체
- HttpServletResponse : 브라우저로 보낼 응답을 “쓰는” 객체
여기서 중요한 관점을 먼저 잡아야 한다.
request는 입력이고, response는 출력이다
request는 읽고, response는 쓴다
request는 “요청 정보를 담은 박스”이다
브라우저가 서버로 보낸 요청에는 여러 정보가 섞여 있다.
- 어떤 주소(URL)로 요청했는지
- GET인지 POST인지
- 파라미터(쿼리 스트링/폼 데이터)는 무엇인지
- 쿠키가 붙어 왔는지
- 브라우저 정보(헤더)는 무엇인지
컨테이너는 이 정보를 파싱해서 HttpServletRequest 객체에 담아준다.
그래서 개발자는 request 객체를 통해 요청 정보를 꺼내 읽는다.
request에서 가장 많이 쓰는 메서드들
1) 요청 방식과 주소 관련
- getMethod()
- 요청이 GET인지 POST인지 확인한다
- getRequestURL() / getRequestURI()
- 사용자가 어떤 URL로 들어왔는지 확인한다
- getServletPath()
- 서블릿이 매핑된 경로를 확인한다
이 메서드들은 “요청이 어디로 어떤 방식으로 들어왔는가”를 파악할 때 쓴다.
2) 파라미터(데이터) 관련
request에서 가장 많이 쓰는 기능은 파라미터 읽기이다.
- getParameter(name)
- 이름(name)에 해당하는 값을 하나 꺼낸다
- 리턴 타입은 항상 String이다
- 값이 없으면 null이 될 수 있다
- getParameterValues(name)
- 같은 이름이 여러 번 전달된 경우 String[]로 받는다
- 체크박스, 다중 선택 같은 경우에 필요하다
- getParameterNames()
- 어떤 파라미터가 들어왔는지 전체 이름을 확인한다
여기서 가장 중요한 주의점은 이것이다.
getParameter는 무조건 String을 돌려준다
숫자가 필요하면 직접 변환해야 한다
값이 없으면 null일 수 있으니 체크해야 한다
3) 헤더 관련
브라우저는 요청을 보낼 때 다양한 헤더를 같이 보낸다.
- getHeaderNames()
- getHeader(name)
로그인을 구현하거나, 쿠키/인코딩/인증 관련 문제를 볼 때 헤더 확인이 자주 필요하다.
4) 쿠키 관련
브라우저가 쿠키를 보내면 request에서 읽을 수 있다.
- getCookies()
이건 세션/로그인 유지로 이어지는 중요한 기반이 된다.
5) “요청 범위 데이터” 저장: setAttribute()
request는 단순히 읽기만 하는 객체가 아니다.
요청 처리 중에 “중간 결과”를 request에 담아두기도 한다.
- setAttribute(key, value)
- getAttribute(key)
이건 주로 MVC에서 컨트롤러(서블릿)가 데이터를 준비해서
JSP로 넘길 때 사용한다.
request에 담긴 데이터는 “현재 요청”이 끝나면 같이 사라진다.
즉 request 범위(scope)에서만 유효하다.
response는 “응답을 만들어 내보내는 객체”이다
response는 서버가 브라우저로 보낼 결과를 구성하는 객체이다.
즉 response는 “출력 담당”이다.
- 어떤 타입으로 응답할지(Content-Type)
- 상태 코드(200, 404, 500 등)
- 헤더 설정
- 실제 바디 출력(HTML/JSON 등)
- 리다이렉트 처리
이런 작업을 response로 한다.
response에서 가장 많이 쓰는 메서드들
1) 응답 타입 설정
- setContentType(...)
예를 들어 HTML을 보낼지, JSON을 보낼지 결정한다.
2) 상태 코드 / 헤더 설정
- setStatus(code)
- setHeader(name, value)
실제 현업에서는 프레임워크가 대신 해주기도 하지만,
기본 원리를 이해할 때는 이게 response의 역할이라는 걸 알아야 한다.
3) 응답 바디 쓰기
- getWriter()
- PrintWriter를 얻어서 문자열 기반 응답을 작성한다
서블릿만으로 HTML을 만들어 보내려면
결국 getWriter().println(...) 같은 형태로 문자열을 출력하게 된다.
그래서 화면 담당을 JSP로 넘기고,
서블릿은 로직 담당으로 쓰는 구조가 자연스럽게 등장한다.
4) 리다이렉트
- sendRedirect(url)
이 메서드는 브라우저에게 “다른 곳으로 이동하라”는 응답을 만든다.
브라우저는 Location 헤더를 보고 실제로 주소를 바꿔 다시 GET 요청을 보낸다.
이게 PRG 패턴과도 연결된다.
5) 쿠키 추가
- addCookie(cookie)
서버가 브라우저에게 쿠키를 발급하거나 갱신할 때 사용한다.
핵심 정리
- request는 입력: 브라우저가 보낸 정보를 읽는다
- response는 출력: 브라우저로 보낼 결과를 만든다
- request는 파라미터/헤더/쿠키/요청 데이터 읽기에 많이 쓴다
- response는 상태코드/헤더/바디 출력/리다이렉트에 많이 쓴다
- request.setAttribute는 “요청 범위 데이터 전달”에 쓰인다
다음 글에서는 “화면을 만들기”에 특화된 JSP로 넘어간다.
서블릿만으로 HTML을 만들면 왜 불편해지는지, JSP는 무엇을 해결하는지부터 정리한다.
'Web > Web Basics' 카테고리의 다른 글
| [서블릿과 JSP] 5. request.getParameter()를 JSP에서 쓰는 방법 (0) | 2026.03.29 |
|---|---|
| [서블릿과 JSP] 4. JSP는 왜 필요한가 (0) | 2026.03.29 |
| [서블릿과 JSP] 2. 서블릿 라이프사이클 (0) | 2026.03.29 |
| [서블릿과 JSP] 1. 서블릿이란? (0) | 2026.03.29 |
| [웹 기초] 9. 개발자 도구(Network)로 request/response를 눈으로 확인하는 방법 (0) | 2026.03.29 |