← Deep Dive /Java Web /17-R5

17-R5. HttpMessageConverter → DispatcherServlet: Response Body 작성 완료

메시지 컨버터의 write(...)가 끝나면, 응답 본문은 이미 HttpServletResponse에 기록된 상태입니다. 이제 DispatcherServlet은 더 이상 뷰 렌더링을 하지 않고 요청을 마무리합니다.

이번 단계의 역할 — JSON 본문 작성이 끝났음을 MVC 흐름에 반영한다

JSON 응답 본문 작성이 끝났음을 MVC 흐름에 반영하는 단계입니다.

호출 흐름 요약 — 컨버터 write() 실행 → 출력 스트림 기록 → handleReturnValue() 종료

  1. writeWithMessageConverters(...)가 적절한 컨버터의 write(...)를 실행합니다.
  2. 컨버터가 응답 출력 스트림에 JSON을 기록합니다.
  3. RequestResponseBodyMethodProcessor.handleReturnValue()가 종료됩니다.
  4. mavContainer.setRequestHandled(true) 상태 덕분에 View 렌더링은 생략됩니다.

호출 흐름 다이어그램 — 컨버터의 write 완료가 DispatcherServlet에 request handled로 전해진다

sequenceDiagram participant Conv as HttpMessageConverter participant Processor as RequestResponseBodyMethodProcessor participant DS as DispatcherServlet Conv-->>Processor: write complete Processor-->>DS: request handled

핵심 코드 — setRequestHandled(true) 뒤 DispatcherServlet은 render()를 건너뛴다

// RequestResponseBodyMethodProcessor.java
mavContainer.setRequestHandled(true);
writeWithMessageConverters(returnValue, returnType, inputMessage, outputMessage);

// DispatcherServlet.java
if (mv != null && !mv.wasCleared()) {
    render(mv, request, response);
}
else {
    logger.trace("No view rendering, null ModelAndView returned.");
}

코드 해설 — requestHandled=true라 DispatcherServlet은 ViewResolver로 내려가지 않는다

REST 응답에서는 requestHandled=true가 이미 설정되어 있기 때문에, DispatcherServlet은 ViewResolver로 내려가지 않습니다. 즉 응답 본문 쓰기가 완료되면 사실상 MVC 응답 처리도 끝난 것입니다.

설계 의도 — 본문 방식과 뷰 방식을 한 파이프라인에 두되 겹치지 않게 끊는다

응답 본문 방식과 뷰 렌더링 방식을 하나의 파이프라인 안에서 공존시키되, 둘이 겹치지 않게 명확히 분기하기 위한 구조입니다.

다음 단계 연결 — 17-R6 JSON 응답이 브라우저에 전달되는 마지막 단계로 이어진다

다음 문서 17-R6에서는 이렇게 작성된 JSON 응답이 최종적으로 브라우저에 전달되는 마지막 단계를 정리합니다.

← 이전: 17-R4. HttpMessageConverter → HttpMessageConverter: JSON 직렬화 | 다음: 17-R6. DispatcherServlet → Browser: HTTP Response (JSON)