Weekly Paper #7

1. 웹 API의 발전과정에서 SOAP에서 REST로 전환이 일어난 이유와 그 장단점

1️⃣ 배경 : 환경의 급격한 변화

• 사용자 급증: 서비스 규모가 커지며 서버의 확장성이 문제가 됨
• 모바일 시대: PC보다 사양이 낮은 스마트폰이 주 기기가 되었음.
• Agile한 개발 문화: 복잡한 표준 규격보다는 빠르게 개발하고 배포하는 유연함이 중요해짐.

2️⃣ SOAP의 한계점

• 무거운 데이터 : XML 기반, 태그가 데이터보다 훨씬 커지는 경우에 낭비가 심해 속도가 느려짐
• 서버 자원 소모: 프로토콜 자체가 무겁고, 세션이나 상태 정보를 유지하려는 경향이 강함. 이로 인해 서버가 감당할 수 있는 사용자 수가 적고, 서버를 늘릴 때 관리가 매우 복잡하다.
• 높은 진입 장벽과 경직성: 반드시 명세서를 작성해야 하고, 이를 해석할 전용 라이브러리가 필수적

3️⃣ SOAP 방식 예시

Request

<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope/"
               soap:encodingStyle="http://www.w3.org/2003/05/soap-encoding">

  <soap:Header>
    <m:AuthHeader xmlns:m="https://www.seungjubank.com/auth">
      <m:ApiKey>SJ-12345-ABCDE</m:ApiKey>
    </m:AuthHeader>
  </soap:Header>

  <soap:Body>
    <m:GetAccountBalance xmlns:m="https://www.seungjubank.com/accounts">
      <m:AccountNumber>12345</m:AccountNumber>
    </m:GetAccountBalance>
  </soap:Body>

</soap:Envelope>

Response

<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope/">

  <soap:Body>
    <m:GetAccountBalanceResponse xmlns:m="https://www.seungjubank.com/accounts">
      <m:Balance>1000000</m:Balance>
      <m:Currency>KRW</m:Currency>
    </m:GetAccountBalanceResponse>
  </soap:Body>

</soap:Envelope>

4️⃣ REST의 장점

• 경량화 (JSON) : 데이터 크기를 줄여 파싱 속도를 향상
• 무상태성 : 서버는 클라이언트의 상태를 저장하지 않음. 대신 클라이언트의 요청이 모든 정보를 담고 있어야 함.
• 표준 HTTP 활용 : 기존 HTTP 메서드를 그대로 활용해 별도 라이브러리 없이 웹 브라우저만으로도 통신이 가능함.

5️⃣ RestAPI 예시

Rest API Request

Method: GET
URL : https://api.seungjubank.com/accounts/12345/balance
{
  "accountNumber": "12345"
}

Rest Api Response

{
  "balance": 1000000,
  "currency": "KRW",
  "status": "success"
}

6️⃣ REST의 단점

• Over-fetching : 서버가 미리 정의한 응답 구조를 그대로 보내주어서 불필요한 데이터를 보내줘 낭비가 심할 수도 있음
• Under-fetching: 한 번의 요청으로 모든 정보를 가져오지 못할 수도 있음 (N+1) 여러 번의 네트워크 요청으로 인해 로딩 시간이 길어짐
• 표준의 부재 : 설계가 자유로워 API 명세서가 없으면 사용법을 직관적으로 알기 어렵고, 협업 시 의사소통 비용이 발생함
• 실시간 통신 부적합성 : REST는 클라이언트가 요청을 보내야 서버가 응답하는 구조이지만, 서버가 먼저 데이터를 PUSH하는 기능에는 적합하지 않다. 이를 해결하기 위해 WebSocket이나 WebHook 같은 별도의 기술이 필요함

-> REST의 단점들 때문에 최근에는 GraphQL, gRPC 같은 기술들이 대안으로 쓰이기도 함.

 

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

1️⃣ Request 수신: DispatcherSevelet이 Client의 request 수신한다.

 

2️⃣ HandlerMapping 조회: HandlerMapping이 요청 url에 맞는 controller를 찾고, url에 맞는 메서드를 찾아줌.

 

3️⃣ HandlerAdapter 실행: HandlerAdapter가 해당 controller의 메서드를 실행한다.

 

4️⃣ 비즈니스 로직 수행: Controller -> Service -> Repository 순으로 비즈니스 로직을 실행하고 DTO를 반환한다.

 

--- ⓐ @RestController 일 때 ---

5️⃣ ReturnValueHandler가 컨트롤러의 반환 값을 JSON로 할지 결정한다!

 

6️⃣ 데이터 변환: HttpMessageConverter가 java 객체를 json으로 반환한다.

 

7️⃣ Response 전달: DispatcherServelet이 반환된 json을 response body에 담아 client에게 전달해준다.

 

 

--- ⓑ @Controller 일 때 ---

5️⃣ ReturnValueHandler가 컨트롤러의 반환 값을 보고 View로 할지 결정한다!

 

6️⃣ 파일 경로 완성 : ViewResolver가 실제 파일의 물리적인 위치를 찾아냄

 

7️⃣ View 렌더링 및 Response 전달: 찾아낸 HTML 파일에 데이터를 입혀서 최종 HTML 문서를 생성

 

 

--- Ⓒ 비즈니스 로직에서 오류가 생겼을 때 ---

5️⃣ 예외 전파: 예외가 Controller를 거쳐 DispatcherServelet 까지 전파됨

 

6️⃣ HandlerExceptionResolver : @RestControllerAdvice에 정의된 적절한 @ExceptionHandler 메서드를 찾아 실행함.

 

7️⃣ 에러 응답 생성: 에러 DTO를 HttpMessageConverter가 JSON으로 변환하여 클라이언트에게 최종 전달.