[위클리 페이퍼] REST API의 장단점과 HTTP 요청 처리 과정

이번주 위클리 페이퍼의 주제는

웹 API의 발전 과정에서 SOAP에서 REST로의 전환이 일어난 이유와 그 장단점에 대해 설명해보자

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

 

 

웹 API의 발전 과정

 

이 문서에서 API 용어의 역사 파트를 정리해보았다.

 

API(Application Programming Interface)는 컴퓨터 간 또는 컴퓨터 프로그램 간의 연결을 뜻한다.

UI가 사용자와 컴퓨터를 연결하는 것 처럼 API는 컴퓨터 또는 소프트웨어끼리 연결해준다.

API는 하나의 소프트웨어 인터페이스이며 다른 소프트웨어에 서비스를 제공한다.

이런 인터페이스를 구축하는 방법을 설명해둔 문서나 표준을 API 명세 라고 한다.

이 명세를 지켜 만들어진 컴퓨터 시스템은 해당 API를 구현했다고 표현한다.

 

프로그래머는 프로그램 안에서 API를 호출(call)해서 사용한다.

API는 서브루틴, 메서드, 요청, 엔드포인트 같은 기능 단위들로 구성되어 있고, 이것들을 언제 어떻게 쓰는지 설명해둔 것이 API 명세이다.

 

API의 목적은 시스템이 동작하는 내부 세부 사항을 숨김으로써 나중에 내부 구현이 변경되더라도 API의 일관성을 유지하는 것이다.

예를들어, 프로그램 내부 구조가 바뀌어도 외부에서 API로 호출하는 방식이 그대로 유지된다면 기존 클라이언트나 앱들이 중단되지 않고 계속 동작한다.

 

1940년대 - API 용어 등장 이전

영국의 컴퓨터 과학자 Maurice Wilkes와 David Wheeler가 초기 컴퓨터 모델인 EDSAC용 모듈형 소프트웨어 라이브러리 작업을 진행했다. 이 라이브러리에는 여러 서브루틴들이 저장되어 있었고, 파일 캐비닛에 정리되어 있었다. 각 캐비닛에는 서브루틴의 설명과 사용 방법이 적힌 라이브러리 카탈로그도 함께 있었다. 오늘날 기준으로 이 문서들은 API 명세 또는 API 문서라고 부를 수 있다.

 

1960-1970년대 - 초기 개념

1968년 AFIPS 학회에서 발표된 논문 『Data structures and techniques for remote computer graphics』에서 처음으로 API라는 용어가 사용되었다.  1974년엔 C. J. Date에 의해 데이터베이스 분야로 도입됐다. 

 

1980년대 - 라이브러리 중심의 API

운영체제(Windows, Unix)와 프로그래밍 언어(Java, C++)에서 사용하는 함수 호출용 라이브러리 API가 표준화된다.

 

1990년대 - 네트워크 기반 API

Tim Berners-Lee가 1991년 WWW를 탄생시킨다. 웹 브라우저, 웹 서버, 웹 문서가 연결되며 인터넷 상호작용이 시작된다.

인터넷을 통해 프로그램끼리 소통하는 네트워크 API 가 등장한다. 이를 위해 SOAP (Simple Object Access Protocol)가 등장한다.

 

2000년대 - REST의 등장

2000년 로이 필딩(Roy Fielding) 박사의 논문 'Architectural Styles and the Design of Network-based Software Architectures' 에서 REST라는 개념 등장한다. REST(Representational State Transfer)는 기존의 SOAP보다 간단하고 직관적인 API 설계 방식이다.

구글, 아마존, 트위터, 페이스북 등에서 RESTful API를 외부 개발자에게 공개하면서 대세가 됐다.

 

SOAP와 REST의 차이

SOAP은 다른 언어로 다른 플랫폼에서 빌드된 애플리케이션이 통신할 수 있도록 설계된 최초의 표준 프로토콜이다.- 레드햇 문서

(HTTP, HTTPS, SMTP 등을 통해 XML 기반의 메시지를 컴퓨터 네트워크 상에서 교환하는 프로토콜이다.)

엄격한 통신 규칙을 정의하고 있다. 

SOAP에서 사용하는 몇가지 표준은 다음과 같다.

• 웹 서비스 보안(WS-Security)은 고유 식별자로 토큰을 사용하는 것과 같은 보안 조치를 지정함
• 웹 서비스 주소 지정(WS-Addressing)에는 라우팅 정보를 메타데이터로 포함해야 함
• WS-ReliableMessaging은 SOAP 메시징의 오류 처리를 표준화함
• 웹 서비스 기술 언어(WSDL)는 SOAP 웹 서비스의 범위와 기능을 설명함

- AWS의 SOAP와 REST에 대한 설명 문서

 

고급 보안, 트랜잭션 처리를 포함한 다양한 기능을 제공해주지만

프로토콜의 장황함, XML의 느린 파싱 속도, 그리고 표준화된 상호작용 모델의 부재로 인해 HTTP 프로토콜을 더 직접적으로 사용하는 서비스 (예: REST) 가 더 우세해졌다. 

 

REST는 API 작동 방식에 대한 조건을 부과하는 소프트웨어 아키텍처 원칙 세트이다.

자원, 행위, 표현으로 이루어져 있으며, 자원은 URI로 식별된다. 행위는 HTTP 프로토콜의 GET, POST, PUT, DELETE 메서드를 사용하여 표현한다. 표현은 자원을 어떤 형식으로 주고받는지에 대한 것이다. JSON이나 XML등이 있다.

아래의 6가지의 아키텍처 가이드라인을 준수하면 RESTful API에 속한다. 

1. Client-Server: 클라이언트와 서버의 역할 분리
2. Stateless: 클라이언트의 모든 요청은 독립적
3. Cache: 응답은 캐시 가능 여부를 명시
4. Uniform Interface: 일관적인 인터페이스로 분리되어야 함
5. Layered System: 클라이언트는 REST API Server만 호출하고, REST Server는 프록시, 로드밸런서 등 여러 계층을 통과할 수 있음
6. (옵션) Code on Demand : 서버가 코드를 클라이언트로 전송하여 실행시키는 기능

REST의 가장 큰 특징으로 유연성이 있지만, 동시에 일관성이 없어질 수 있다는 문제가 있다.

또한 고정된 엔드포인트 구조이기 때문에 불필요한 데이터까지 모두 받아오는 Over-fetching 문제나 반대로 사용자가 필요로 하는 데이터를 한 번에 얻어오지 못하고 여러번 요청해야 하는 Under-fetching 문제가 발생할 수 있다.

 

SOAP는 프로토콜이지만 REST는 아키텍처 스타일이기 때문에 세부적인 비교를 하기엔 적절하지 않다.

하지만 SOAP는 REST보다 단순성이 떨어지고, 웹 친화성도 떨어지며 XML의 무겁고 느린 특징까지 더해져 REST로의 전환이 일어났다.

 

 

@RestController

저번주 위클리 페이퍼 게시글에 Spring Boot의 @RestController에 대한 간단한 설명을 적어두었다.

https://nanunyagyami.tistory.com/16

[위클리 페이퍼] AOP, @Controller와 @RestController

이번엔 HTTP 메시지 컨버터가 동작하는 시점과 역할을 포함하여 요청이 응답을 변환되는 과정을 설명한다.

 

HTTP 메시지 컨버터(HttpMessageConverter)는 HTTP 요청/응답의 Body를 자바객체 ↔ JSON, XML, 문자열 등으로 자동 변환해주는 Spring의 기능이다.

• 요청의 경우, JSON → 자바 객체로 역직렬화 해준 뒤 컨트롤러에 파라미터로 넘겨주는 역할
• 응답의 경우, 컨트롤러에서 리턴 값을 가지고 자바 객체 → JSON 으로 직렬화 하여 Http 응답 메시지로 넣는 역할

 

HTTP 요청이 처리되어 응답으로 변환되는 전체 과정

클라이언트 HTTP 요청
       ↓
디스패처 서블릿 (DispatcherServlet)
       ↓
핸들러 매핑 (HandlerMapping)
       ↓
컨트롤러 (@RestController)
       ↓
핸들러 어댑터 (HandlerAdapter)
       ↓
HTTP 메시지 컨버터 (HttpMessageConverter)
       ↓
응답 객체 → JSON (또는 XML 등) 변환
       ↓
HTTP 응답 반환

 

1. 클라이언트가 HTTP 요청을 보냄 (예시: GET /api/users/1  )

2. DispatcherServlet이 요청을 받음 ( 요청을 받아서 어떤 컨트롤러 메서드가 처리할지 결정)

3. HandlerMapping이 해당 요청을 처리할 @RestController의 메서드를 찾음

4. 컨트롤러 메서드 호출

5. HandlerAdapter가 컨트롤러의 리턴값을 받아서 View or Body로 변환할 준비

(@RestController는 @ResponseBody가 포함되어 있기 때문에 뷰 이름을 찾지 않고, 바로 HTTP 응답 바디에 출력할 데이터를 찾음)

< HttpMessageConverter가 동작하는 시점>

6. 리턴된 자바 객체(User 등)를 클라이언트가 요청한 형식(JSON, XML 등)으로 변환하는 역할

7. 변환된 결과가 HTTP 응답으로 전달됨