위클리 페이퍼 - 7주차

1.웹 API의 발전 과정에서 SOAP에서 REST로의 전환이 일어난 이유와 그 장단점에 대해 설명하세요.

SOAP에서 REST로 전환된 주요 이유

1. 복잡성과 오버헤드 문제

SOAP의 문제:

xml
<!-- 단순한 요청도 복잡한 XML 구조 -->
<soap:Envelope>
  <soap:Body>
    <getTemperature>
      <city>Seoul</city>
    </getTemperature>
  </soap:Body>
</soap:Envelope>

 

REST의 해결:

http
GET /weather/seoul/temperature

2. 웹 브라우저와의 호환성

SOAP의 한계:

• 브라우저에서 직접 테스트하기 어려움
• JavaScript로 SOAP 메시지 생성/파싱 복잡
• 추가 라이브러리나 프록시 필요

REST의 장점:

• 브라우저 주소창에서 직접 테스트 가능
• AJAX로 쉽게 호출 가능
• JSON 사용으로 JavaScript와 자연스러운 통합

3. 모바일과 경량 클라이언트의 등장

모바일 환경의 요구사항:

• 제한된 대역폭과 배터리
• 단순한 데이터 형식 선호
• 빠른 파싱과 처리 필요

REST의 적합성:

json
// 간단하고 가벼운 JSON 응답
{
  "id": 123,
  "name": "John Doe",
  "email": "john@example.com"
}

 

5. 각각의 장단점 비교

SOAP의 장점

1. 강력한 표준화

• WSDL을 통한 명확한 인터페이스 정의
• 자동 코드 생성 도구 지원
• 타입 안정성 보장

2. 엔터프라이즈 기능

• WS-Security: 강력한 보안 기능
• WS-Transaction: 분산 트랜잭션 지원
• WS-ReliableMessaging: 메시지 전달 보장

3. 프로토콜 독립성

• HTTP 외에도 다양한 전송 프로토콜 지원
• 네트워크 토폴로지에 유연하게 대응

SOAP의 단점

1. 복잡성과 오버헤드

xml
<!-- 실제 데이터보다 메타데이터가 더 많은 경우 -->
<soap:Envelope>
  <soap:Header>...</soap:Header>
  <soap:Body>
    <response><value>42</value></response>
  </soap:Body>
</soap:Envelope>

 

2. 성능 문제

• XML 파싱 비용
• 큰 메시지 크기
• 복잡한 처리 로직

3. 개발자 경험

• 높은 학습 곡선
• 복잡한 디버깅
• 도구 의존성

REST의 장점

1. 단순성과 직관성

http
# 직관적인 URL 구조
GET /api/users/123/posts
POST /api/users/123/posts

 

2. 웹 친화적

• HTTP 캐싱 활용
• CDN 지원
• 브라우저 개발자 도구로 쉬운 디버깅

3. 확장성

• Stateless 특성으로 수평 확장 용이
• 로드 밸런싱과 캐싱 최적화

4. 개발자 친화성

• 낮은 진입 장벽
• 다양한 클라이언트 지원
• 풍부한 생태계

REST의 단점

1. 표준화 부족

• 구현마다 다른 규칙
• 일관성 없는 API 설계
• 문서화 도구의 필요성

2. 제한된 기능

• 복잡한 트랜잭션 처리 어려움
• 실시간 통신 제약
• 타입 안정성 부족

3. HTTP 의존성

• HTTP 외 프로토콜 지원 제한
• HTTP의 한계 상속

SOAP에서 REST로의 전환은 단순히 기술적 변화가 아니라 웹 생태계의 발전과 개발자 커뮤니티의 요구사항 변화를 반영한 패러다임 전환이었습니다. 각 기술은 고유한 장점과 적용 영역을 가지고 있어, 현재도 상황에 맞는 적절한 선택이 중요합니다.

 

나만의 언어로 정리해보기

SOAP의 장점과 단점
장점

- 강력한 표준화

- 엔터프라이즈 기능

- 프로토콜 독립성

단점

- 복잡성과 오버헤드

- 성능 문제

- 개발자 경험

 

REST의 장점과 단점
장점

- 웹 친화적

- 확장성

- 개발자 친화성

단점

- 표준화 부족

- 제한된 기능

- HTTP 의존성

 

SOAP에서 REST로 전환된 주요 이유
- 복잡성과 오버헤드 문제
- 웹 브라우저와의 호환성
- 모바일과 경량 클라이언트의 등장

 

Spring Boot에서 @RestController로 들어온 HTTP 요청이 처리되어 응답으로 변환되는 전체 과정을 설명하세요. 특히 HTTP 메시지 컨버터가 동작하는 시점과 역할을 포함해서 설명하세요.

@RestController로 들어온 HTTP 요청이 처리되어 응답으로 변환되는 과정

1. 요청 수신 및 초기 처리
   • 내장 서블릿 컨테이너(Tomcat 등)가 HTTP 요청을 수신
   • DispatcherServlet이 모든 HTTP 요청의 진입점 역할을 수행
   • doDispatch() 메서드가 실제 요청 처리를 시작
2. HandlerMapping을 통한 핸들러 찾기
   • RequestMappingHandlerMapping이 요청 URL, HTTP 메서드를 분석
   • @RequestMapping, @GetMapping 등의 어노테이션 정보와 매칭
   • 적절한 컨트롤러의 핸들러 메서드를 찾아 HandlerExecutionChain 반환
3. HandlerAdapter 선택 및 전처리
   
   • RequestMappingHandlerAdapter가 선택됨
   • ArgumentResolver들이 핸들러 메서드의 파라미터를 해결
   • 이 과정에서 HTTP 메시지 컨버터가 첫 번째로 동작
4. HTTP 메시지 컨버터의 역할 (요청 처리 시)
   • 동작 시점: ArgumentResolver가 @RequestBody 파라미터를 처리할 때
   • 처리 과정
     • RequestResponseBodyMethodProcessor가 @RequestBody 어노테이션을 감지
     • HTTP 요청의 Content-Type 헤더 확인 (예: application/json)
     • 적절한 HttpMessageConverter 선택 (예: MappingJackson2HttpMessageConverter)
     • 요청 본문의 JSON을 Java 객체로 변환 (역직렬화)
5. 핸들러 메서드 실행
   • 변환된 파라미터들과 함께 실제 컨트롤러 메서드 실행
   • 비즈니스 로직 처리 후 결과 객체 반환
6. HTTP 메시지 컨버터의 역할 (응답 처리 시)
   • 동작 시점: ReturnValueHandler가 반환값을 처리할 때
   • 처리 과정
     • RequestResponseBodyMethodProcessor가 @RestController의 반환값을 처리
     • 클라이언트의 Accept 헤더와 반환 객체 타입을 분석
     • 적절한 HttpMessageConverter 선택
     • Java 객체를 HTTP 응답 형태로 변환 (직렬화)
     • Content-Type 헤더 설정 (예: application/json)
7. 응답 생성 및 전송
   • HttpServletResponse에 변환된 데이터 작성
   • HTTP 상태 코드, 헤더 정보 설정
   • 클라이언트로 최종 응답 전송

나만의 언어로 정리해보기

RestController로 들어온 HTTP 요청이 처리되어 응답으로 변환되는 전체 과정
1. 요청 수신 및 초기 처리
2. HandlerMapping을 통한 핸들러 찾기
3. Handleradepter 선택 및 전처리
4. HTTP 메시지 컨버터의 역할 (요청 처리 시)
5. 핸들러 메서드 실행
6. HTTP 메시지 컨버터의 역할 (응답 처리 시)
7. 응답 생성 및 전송