티스토리 뷰
웹 API의 발전 과정에서 SOAP에서 REST로의 전환이 일어난 이유와 그 장단점에 대해 설명하세요.
SOAP란?
SOAP(Simple Object Access Protocol)은 서로 다른 시스템 간의 정형화된 메시지 통신을 위해 만들어진 프로토콜
SOAP의 주요 특징
2000년대 초반 웹 서비스를 지배
XML 기반 메시지 포맷
엄격한 규격(표준) 존재
WSDL(Web Services Description Language)로 API 명세 제공
HTTP 외에도 SMTP, TCP 등 다양한 전송 프로토콜 사용 가능
SOAP의 한계
SOAP은 엔터프라이즈 환경에서는 강력했지만, 웹이 대중화되면서 여러 한계가 드러났다
XML 기반 → 메시지 크기 큼
- 파싱 비용 증가
- 개발 생산성 저하
WSDL 작성 필수
- 설정과 코드가 과도하게 많음
- 웹 친화적이지 않음
HTTP를 단순한 전송 수단으로만 사용
- URI, HTTP Method의 의미를 활용하지 못함
모바일·브라우저 환경에 부적합
- 가볍고 빠른 통신이 필요한 환경에 부담
REST란 무엇인가?
그래서 2000년대 중반 이후, Roy Fielding의 논문을 기반으로 한 REST(Representational State Transfer)가 대중화되기 시작
REST는 프로토콜이 아니라 아키텍처 스타일이다.
즉, “이렇게 설계하면 좋다”라는 설계 원칙의 집합이다.
REST의 핵심 개념
1. 자원(Resource) 중심 설계
2. URI로 자원 식별
3. HTTP Method로 행위 표현
- GET : 조회
- POST : 생성
- PUT : 수정
- DELETE : 삭제
4. Stateless (무상태성)
SOAP에서 REST로 전환된 이유
단순함과 가독성
- REST는 XML 대신 JSON 사용이 일반적
- 메시지가 짧고 읽기 쉬움
HTTP를 제대로 활용
- 상태 코드 (200, 400, 404, 500 등)
- 캐싱, 인증, 보안 메커니즘 활용 가능
높은 개발 생산성
- 복잡한 명세(WSDL) 없이도 개발 가능
- 프론트엔드·모바일과 궁합이 좋음
확장성과 유연성
- 마이크로서비스 아키텍처에 적합
- 다양한 클라이언트 지원
요약
SOAP은 “정확하고 엄격한 기업용 통신”,
REST는 “가볍고 유연한 웹 중심 통신”이다.
웹과 모바일 중심의 시대가 오면서,
단순함·확장성·개발 생산성을 앞세운 REST가 주류가 되었다.
Spring Boot에서 @RestController로 들어온 HTTP 요청이 처리되어 응답으로 변환되는 전체 과정을 설명하세요. 특히 HTTP 메시지 컨버터가 동작하는 시점과 역할을 포함해서 설명하세요.
HTTP 요청 처리 전체 과정 (Flow)
Spring Boot에서 @RestController로 요청이 들어오면 다음의 순서를 거친다
1. 클라이언트 요청: 브라우저나 앱에서 JSON 데이터를 담아 서버로 HTTP 요청을 보냄
2. DispatcherServlet 수신: 모든 요청의 관문인 DispatcherServlet이 요청을 받음
3. 핸들러 조회: HandlerMapping을 통해 요청 URL을 처리할 컨트롤러(핸들러)를 찾음
4. 핸들러 어댑터 결정: 찾은 컨트롤러를 실행할 수 있는 HandlerAdapter를 가져옴
(보통 RequestMappingHandlerAdapter가 사용된다)
5. 파라미터 준비 및 컨버터 동작 (입력): 컨트롤러 메서드를 실행하기 전, 필요한 인자(Argument)를 만듦
이때 HTTP 메시지 컨버터가 작동한다
6. 컨트롤러 실행: 비즈니스 로직을 처리하고 결과 객체를 반환
7. 응답 처리 및 컨버터 동작 (출력): 반환된 객체를 클라이언트에 보낼 형식으로 바꿈
이때 다시 한번 HTTP 메시지 컨버터가 작동
8. 응답 전송: 최종 변환된 데이터(JSON 등)를 HTTP 응답 바디에 실어 보냄
HTTP 메시지 컨버터의 동작 시점과 역할
@RestController는 일반 @Controller와 달리 데이터 자체(JSON, XML 등)를 직접 반환하는 것이 목적
메시지 컨버터는 위 흐름 중 5번(입력)과 7번(출력) 시점에서 핵심적인 역할을 수행함
요청 시 (Reading): JSON → 객체
사용자가 보낸 JSON 데이터를 자바 객체로 바꾸는 과정
시점: 컨트롤러 메서드의 파라미터에 @RequestBody가 붙어 있을 때 실행
역할: RequestMappingHandlerAdapter가 **HttpMessageConverter**를 호출하여 HTTP Body에 담긴 JSON 문자열을 자바 객체(DTO)로 변환해 컨트롤러에 전달
응답 시 (Writing): 객체 → JSON
컨트롤러가 반환한 자바 객체를 다시 JSON으로 바꾸는 과정
시점: 컨트롤러 메서드에 @ResponseBody가 붙어 있거나(또는 @RestController일 때), 메서드가 리턴될 때 실행
역할: 반환된 객체를 보고 어떤 컨버터를 쓸지 결정
(예: 객체면 MappingJackson2HttpMessageConverter를 사용하여 JSON으로 변환)
요약
동작 원리: @RestController 요청 처리는 DispatcherServlet에서 시작해 HandlerAdapter를 거치며, 이 과정에서 HTTP 메시지 컨버터가 데이터 변환을 전담
입력 시점: @RequestBody를 만나면 컨버터가 작동하여 HTTP Body의 JSON을 자바 객체로 변환해 컨트롤러에 전달
응답 시점: @ResponseBody가 있으면 컨트롤러가 반환한 자바 객체를 다시 JSON으로 변환하여 클라이언트에게 최종 응답을 보냄