대부분의 API Gateway 솔루션에서 '집계'가 지원되지 않는 이유는 무엇입니까?

API Gateway에 대해 읽을 때 매번 나타나는 것은 API Gateway가 여러 엔드 포인트의 결과를 집계해야하는 곳입니다. 정말 좋네요 그러나 AWS API Gateway, Kongo 및 Netflix Zuul과 같이 널리 사용되는 많은 API 게이트웨이 솔루션은 이러한 기능을 지원하지 않습니다. 해킹하거나 사용자 정의 필터를 직접 구현해야합니다.

집계가 나쁜 습관으로 간주됩니까? 사람들이 여러 엔드 포인트에서 결과를 어떻게 반환합니까?

이 질문에 대답 할 수있는 여러 가지 방법이 있습니다.

엔드 포인트 집계

API 게이트웨이는 대부분 다른 엔드 포인트를 집계하며 반드시 결과는 아닙니다. 즉, 인증 또는 라우팅과 같은 추가 기능이있는 다른 엔드 포인트를 미러링 할 수있는 단일 서버입니다.

요점은 일부 서비스를 중앙 집중화하고 외부 네트워크에서 실제 서버를 숨기는 등입니다.

결과 집계

게이트웨이에서 비즈니스 로직을 원하거나 다른 문서를 다른 문서로 가져 오거나 요청 또는 응답을 변경하려는 경우 엔터프라이즈 서비스 버스를 보고있을 수 있습니다 .

집계가 좋은지 여부

이것은 물론 논쟁의 여지가 있으며 개인의 의견에 달려 있습니다. SOA / ESB 유형 솔루션에서 (주로) 멀리 떨어진 이유가 있다고 주장 할 수 있습니다. 이러한 이유는 개별 책임이 명확하지 않고 ESB 측에서 수집하여 엔드 포인트를 "멍청한"상태로 두는 경향이 있기 때문일 수 있습니다. 결국 ESB는 모든 것을 알고 있습니다.

"REST"접근 방식이 다릅니다. "스마트 한"엔드 포인트를 기반으로 구성 요소를 알고 있으며 다른 구성 요소가 세부 정보를 알 필요가 없도록합니다. 이 아이디어 자체는 게이트웨이가 응답에 대해 더 많이 알리는 것과 충돌하는 것 같습니다 .

실제로 자체 구축 시스템 과 같은 일부 아키텍처 아이디어 는 아이디어를 기반으로 클라이언트가 필요로하는 모든 기능을 주어진 엔드 포인트 로 완전히 커버 해야 한다는 아이디어를 기반으로 합니다. 그것은 안된다 책임을 자신의 영역에서 요청을 이행하기 위해 다른 사람들과 동기 통신을해야합니다. 또한 집계 결과가 비생산적 일 수 있음을 나타냅니다.

항상 그렇듯이, 그것은 모두 정확한 요구 사항에 달려 있습니다.