REST API 통신

REST 아키텍처 패턴에서는 일반적으로 동기 통신을 사용한다.
그 말인 즉, REST API의 클라이언트는 HTTP 엔드포인트를 호출할 때마다 즉각적인(약 60초 내) 응답을 기대하고, 제한 시간 내에 응답을 받지 못하면 시간 초과 메시지와 에러를 던진다.

그렇다면 제출된 요청을 처리하는 데 오랜 시간이 걸릴 것으로 예상되면 어떻게 해야 될까?

클라이언트가 응답을 기다리지 않고, 요청이 처리된 후 결과를 확인할 수 있도록 비동기 통신을 고려해 볼 수 있다.

비동기 통신을 사용하면 클라이언트는 응답을 기다리는 시간을 효율적으로 사용할 수 있다. 또한, 동기 통신이었다면 응답을 기다렸을 스레드가 block 상태가 되지 않고, 다른 작업에 사용 가능하다. 서버도 마찬가지이다. 외부 API 호출을 기다리는 제약을 제거할 수 있다.

오랜 시간이 걸리는 복잡한 작업은 간단한 작업보다 더 많은 오류를 발생시키는 경향이 있다. 비동기 통신의 경우, 트랜잭션에서 문제가 발생해도 서버는 전체 프로세스를 다시 시작하고 사용자에게 결과를 알릴 수 있다.

더 자세한 사항은 대표적인 비동기 통신 모델을 살펴보며 알아보자.

비동기 통신

Polling Model

Polling
다른 프로그램의 상태를 주기적으로 검사하여 일정 조건을 만족할 때 데이터를 처리하는 방식

클라이언트는 서비스에 요청을 보내 작업을 제출하고, 제출한 작업과 관련된 토큰을 즉시 응답받는다. 클라이언트는 제출한 작업의 상태를 추적하기 위해 이 토큰을 사용하여 서비스를 폴링해야 한다.

만약 서버의 응답이 지연될 경우, 클라이언트 스레드는 여러번 응답을 확인해야 하므로 오버헤드가 발생할 수 있다. 또한, 클라이언트는 작업 상태를 추적하고 응답을 가져오는 책임을 갖게 된다.

그러나 동기적으로(클라이언트가 원하는 시점에) 서버의 응답을 확인할 수 있다는 장점이 있다. 또한, 클라이언트 측에서 중단이 발생하는 경우 클라이언트가 제출한 작업에 대한 폴링을 재개할 수 있으므로 제출된 작업의 상태/출력이 손실되지 않는다. 특히, 클라이언트 측 인바운드 트래픽이 허용되지 않는 네트워크 설정(조직 방화벽)에 있는 경우에 유리하다.

Callback Model

클라이언트(Caller)는 요청을 보낸 후 응답이 오는 것을 신경쓰지 않는다. 서버(Callee)에서 작업이 완료된 후에는 지정된 콜백(Callback) URI를 통해 응답을 전달받는다.

이러한 콜백 모델에서는 통제권의 역전이 일어난다. 작업이 완료되면 클라이언트에게 작업 결과를 알리는 것이 서비스의 책임이 된다. 또한, 클라이언트가 서비스 end-point을 노출하고, 서비스 end-point을 콜백 URI로 서비스에서 사용하게 된다. 따라서, 클라이언트는 더 이상 단순한 클라이언트가 아니며 이제 서버이기도 하다.

특히 서버의 응답이 비동기적이어도 문제가 되지않을 때 사용한다. 서버의 응답을 여러번 확인하지 않아도 된다는 장점이 있으나, 콜백이 누락될 수 있다.

 

---

참고사이트
https://sanketdaru.com/blog/polling-model-async-rest-spring-boot/
https://stackoverflow.com/questions/23580494/why-callback-in-rest-api
https://qkfmxha.tistory.com/55