GraphQL과 REST: 차이점은 무엇인가요?

소프트웨어 구성 요소가 상호 작용하고 데이터가 인터넷을 통해 이동하는 통로인 API는 최신 웹 서비스의 생명선입니다. SOAP(웹 서비스 메시징 프로토콜), REST(아키텍처 스타일) 및 GraphQL(프로그래밍 언어 및 도구)과 같은 API 기술은 타사 데이터 및 서비스 통합을 가능하게 하여 소프트웨어 개발을 간소화합니다. 또한 기업은 API를 통해 직원, 비즈니스 파트너 및 사용자에게 안전한 서비스 기능과 데이터 교환을 제공할 수 있습니다.

다양한 유형의 API가 존재하지만 최근 몇 년 동안 두 가지 주요 패러다임에 대한 논의가 주를 이뤘습니다. 바로 REST(표현 상태 전송)와 GraphQL입니다. 두 가지 모두 다양한 이점을 제공하기 때문에 전 세계의 네트워킹 프로젝트에 배포되고 있습니다. 그러나 이들이 데이터 트래픽을 관리하는 방법은 크게 다릅니다. 여기에서는 이러한 차이점을 자세히 분석하고 기업이 REST 및 GraphQL API를 사용하여 네트워크를 최적화하는 방법에 대해 설명합니다.

REST 및 GraphQL API란 무엇인가요?

이 둘을 비교하려면 REST 및 GraphQL API를 개별적으로 이해해야 합니다.

REST

2000년대 초에 개발된 REST는 네트워크 하이퍼미디어 애플리케이션을 위한 구조화된 아키텍처 스타일로, 상태 비저장, 클라이언트/서버, 캐시 가능한 통신 프로토콜을 사용하도록 설계되었습니다. RESTful API라고도 하는 REST API는 REST 아키텍처의 드라이버입니다.

REST API는 고유 리소스 식별자(URI)를 사용하여 리소스를 처리합니다. REST API는 서로 다른 엔드포인트가 네트워크 리소스에 대한 CRUD("만들기", "읽기", "업데이트" 및 "삭제") 작업을 수행하도록 하여 작동합니다. 이는 미디어 형식 또는 MIME 형식이라고 하는 미리 정의된 데이터 형식을 사용하여 클라이언트에 제공하는 리소스의 모양과 크기를 결정합니다. 가장 일반적인 형식은 JSON 및 XML(때로는 HTML 또는 일반 텍스트)입니다.

클라이언트가 리소스를 요청하면 서버는 쿼리를 처리하고 해당 리소스와 관련된 모든 데이터를 반환합니다. 응답에는 "200 OK"(성공적인 REST 요청의 경우) 및 "404 Not Found"(존재하지 않는 리소스의 경우)와 같은 HTTP 응답 코드가 포함됩니다.

GraphQL

GraphQL은 2015년 오픈 소스가 되기 전에 Facebook이 2012년에 내부적으로 개발한 쿼리 언어 및 API 런타임입니다.

GraphQL은 GraphQL 스키마 정의 언어로 작성된 API 스키마로 정의됩니다. 각 스키마는 사용자가 쿼리하거나 수정할 수 있는 데이터 유형과 유형 간의 관계를 지정합니다. 리졸버는 스키마에서 각 필드를 백업합니다. 리졸버는 GraphQL 쿼리, 변형 및 구독을 데이터로 변환하기 위한 지침을 제공하고 데이터베이스, 클라우드 서비스 및 기타 소스에서 데이터를 검색합니다. 또한 리졸버는 데이터 형식 사양을 제공하고 시스템이 다양한 소스의 데이터를 함께 연결할 수 있도록 합니다.

일반적으로 여러 엔드포인트를 사용하여 데이터를 가져오고 네트워크 작업을 수행하는 REST와 달리 GraphQL은 클라이언트가 요청하는 내용에 관계없이 GraphQL 요청을 보내는 단일 엔드포인트를 사용하여 데이터 모델을 노출합니다. 그런 다음 API는 리소스 속성에 액세스하고 리소스 간의 참조를 따라 단일 쿼리에서 GraphQL 서버로 필요한 모든 데이터를 클라이언트에 가져옵니다.

GraphQL 및 REST API는 모두 클라이언트가 수행할 수 있는 작업을 지정하는 HTTP 메서드(예: PUT 및 GET 요청)를 사용하는 리소스 기반 데이터 교환입니다. 그러나 GraphQL의 확산뿐만 아니라 RESTful 시스템이 그토록 오래 지속되는 이유를 설명하는 주요 차이점이 있습니다.

GraphQL과 REST API의 차이점

GraphQL은 REST에 효율적이고 유연한 추가 기능을 제공합니다. GraphQL API는 특히 프런트엔드 팀과 백엔드 팀 간의 협업을 용이하게 하는 기능을 감안할 때 RESTful 환경의 업그레이드로 간주되는 경우가 많습니다. GraphQL은 조직의 API 여정에서 논리적인 다음 단계를 제공하여 REST에서 자주 발생하는 문제를 해결하는 데 도움이 됩니다.

그러나 REST는 오랫동안 API 아키텍처의 표준이었으며 많은 개발자와 아키텍트는 여전히 RESTful 구성에 의존하여 IT 네트워크를 관리합니다. 따라서 둘 사이의 차이점을 이해하는 것은 모든 조직의 IT 관리 전략에 필수적입니다.

REST 및 GraphQL API는 관리 방식이 다릅니다.

데이터 검색

REST는 여러 엔드포인트와 상태 비저장 상호 작용(모든 API 요청이 다른 요청과 독립적으로 새 쿼리로 처리됨)에 의존하기 때문에 클라이언트는 리소스와 연결된 모든 데이터를 수신합니다. 클라이언트가 데이터의 일부만 필요한 경우에도 모든 데이터를 수신합니다(오버페치). 또한 클라이언트가 여러 리소스에 걸쳐 있는 데이터를 필요로 하는 경우 RESTful 시스템은 초기 요청에서 부적절한 데이터 검색(언더페치)을 보상하기 위해 클라이언트가 각 리소스를 개별적으로 쿼리하도록 하는 경우가 많습니다. GraphQL API는 단일 GraphQL 엔드포인트를 사용하여 단일 요청에서 한 번의 왕복 이동으로 고객에게 정확하고 포괄적인 데이터 응답을 제공하여 오버페치 및 언더페치 문제를 제거합니다.

버전 관리

REST 아키텍처에서 팀은 데이터 구조를 수정하고 최종 사용자의 시스템 오류 및 서비스 중단을 방지하기 위해 API의 버전을 지정해야 합니다. 즉, 개발자는 변경할 때마다 새로운 엔드포인트를 만들어야 하므로 여러 API 버전을 만들고 유지 관리가 복잡해질 수 있습니다. GraphQL은 클라이언트가 쿼리에서 데이터 요구 사항을 지정할 수 있기 때문에 버전 관리가 필요 없어집니다. 서버에 새 필드를 추가해도 해당 필드가 필요 없는 클라이언트에는 영향을 미치지 않습니다. 반대로 필드가 더 이상 사용되지 않는 경우 클라이언트는 쿼리가 업데이트될 때까지 필드를 계속 요청할 수 있습니다.

오류 처리

REST API는 HTTP 상태 코드를 사용하여 요청의 상태 또는 성공을 나타내야 하며 각 상태 코드에는 특정 의미가 있습니다. 성공적인 HTTP 요청은 200 상태 코드를 반환하지만, 클라이언트 오류는 일반적으로 400 상태 코드를, 서버 오류는 일반적으로 500 상태 코드를 반환합니다.

언뜻 보기에는 상태 보고에 대한 이러한 접근 방식이 더 간단해 보이지만 HTTP 상태 코드는 특히 오류의 경우 API 자체보다 웹 사용자에게 더 유용한 경우가 많습니다. REST에는 오류에 대한 사양이 없으므로 API 오류는 전송 오류로 표시되거나 상태 코드와 함께 전혀 표시되지 않을 수 있습니다. 이러한 역학 관계로 인해 직원은 상태 문서를 읽고 오류가 무엇을 의미하는지 또는 인프라 내에서 오류가 전달되는 방식을 이해해야 할 수 있습니다.

GraphQL API를 사용하면 오류가 발생했는지 여부에 관계없이 오류가 HTTP 상태 코드를 사용하여 전달되지 않기 때문에 모든 요청은 200 OK 상태 코드를 반환합니다(전송 오류 제외). 대신 시스템은 데이터와 함께 응답 본문에서 오류를 전달하므로 클라이언트는 데이터 페이로드를 파싱하여 요청이 성공했는지 확인해야 합니다.

즉, GraphQL에는 오류에 대한 사양이 있으므로 API 오류를 전송 오류와 더 쉽게 구별할 수 있습니다. 오류의 정확한 성격은 응답 본문의 '오류' 항목에 나타나므로 GraphQL API를 빌드하는 데 더 유리할 수 있습니다.

실시간 데이터

REST에는 실시간 업데이트를 기본적으로 지원하지 않습니다. 앱에 실시간 기능이 필요한 경우 개발자는 일반적으로 롱 폴링(클라이언트가 새 데이터를 찾기 위해 서버를 반복적으로 폴링하는 것) 및 서버 전송 이벤트와 같은 기술을 구현해야 하며, 이로 인해 애플리케이션이 더 복잡해질 수 있습니다.

그러나 GraphQL에는 구독을 통한 실시간 업데이트에 대한 기본 제공 지원이 포함되어 있습니다. 구독은 서버에 대한 안정적인 연결을 유지하여 특정 이벤트가 발생할 때마다 서버가 클라이언트에 업데이트를 푸시할 수 있도록 합니다.

툴 및 환경

REST 환경은 개발자가 사용할 수 있는 다양한 툴, 라이브러리 및 프레임워크와 함께 잘 구축되어 있습니다. 그럼에도 불구하고 REST API로 작업하려면 팀이 여러 엔드포인트를 탐색하고 각 API의 고유한 규칙과 패턴을 이해해야 합니다.

GraphQL API는 비교적 최근에 나왔지만, 도입 이후 GraphQL 환경은 서버 및 클라이언트 개발에 사용할 수 있는 다양한 툴과 라이브러리를 통해 급속히 발전해 왔습니다. GraphiQL 및 GraphQL Playground와 같은 툴은 GraphQL API를 탐색하고 테스트할 수 있는 강력한 브라우저 내 통합 개발 환경(IDE)을 제공합니다. 또한 GraphQL은 클라이언트 측 개발을 간소화할 수 있는 코드 생성을 강력하게 지원합니다.

캐싱

REST API는 eTags 및 마지막으로 수정된 헤더와 같은 메커니즘을 사용하여 API 호출을 캐시합니다. 이러한 캐싱 전략은 효과적이긴 하지만 구현하기가 복잡할 수 있으며 모든 사용 사례에 적합하지는 않을 수 있습니다.

GraphQL API는 쿼리의 동적 특성으로 인해 캐시하기가 더 어려울 수 있습니다. 그러나 지속형 쿼리, 응답 캐싱 및 서버 측 캐싱을 배포하면 이러한 문제를 완화하고 GraphQL 아키텍처에서 더 광범위한 캐싱 작업을 간소화할 수 있습니다.

GraphQL 및 REST API를 사용해야 하는 경우

REST나 GraphQL API는 본질적으로 우수하지 않습니다. 이들은 다양한 작업에 적합한 다양한 툴입니다.

REST는 일반적으로 구현하기가 더 쉬우며 엄격한 액세스 제어를 갖춘 간단하고 캐싱이 가능한 통신 프로토콜을 선호하는 경우(예: Shopify 및 GitHub와 같은 공용 전자 상거래 사이트의 경우) 좋은 선택이 될 수 있습니다.
오버페치 및 언더페치 위험을 고려할 때 REST API는 다음과 같은 경우에 가장 적합합니다.

더 간단한 데이터 프로필로 소규모 앱을 사용하는 기업
복잡한 데이터 쿼리 요구 사항이 없는 기업
대부분의 고객 기반이 유사한 방식으로 데이터와 운영을 사용하는 기업

GraphQL API는 보다 유연하고 효율적인 데이터 가져오기를 지원하여 개발자의 시스템 성능과 사용 편의성을 향상시킬 수 있습니다. 이러한 기능 덕분에 GraphQL은 프런트엔드 요구 사항이 빠르게 변화하는 복잡한 환경에서 API를 구축하는 데 특히 유용합니다. 여기에는 다음이 포함됩니다.

대역폭이 제한되어 있어 통화 및 응답을 제한하려는 기업
하나의 엔드포인트에서 데이터 포인트를 결합하려는 기업
고객 요청이 매우 다양한 기업

GraphQL과 REST API는 서로 다른 접근 방식을 사용하지만 둘 모두 네트워크 확장성과 서버 성능을 크게 향상시킬 수 있는 잠재력을 가지고 있습니다.

IBM API Connect로 API 환경 제어

REST 또는 GraphQL API를 배포하든, 이 둘을 조합하여 배포하든, 비즈니스는 다양한 프로그래밍 언어(예: JavaScript)로 구현하고 마이크로서비스 및 서버리스 아키텍처와 통합하는 등 광범위한 잠재적 애플리케이션을 활용할 수 있습니다. IBM API Connect를 사용하면 두 API 유형을 모두 사용하여 IT 인프라를 최적화할 수 있습니다.

IBM API Connect는 API를 생성, 관리, 보안, 소셜화 및 수익화하고 데이터 센터 및 클라우드 환경 전반에서 디지털 혁신을 촉진하는 데 도움이 되는 전체 라이프사이클 API 관리 솔루션입니다. 이를 통해 비즈니스와 고객 모두가 디지털 앱을 구동하고 실시간으로 혁신을 추진할 수 있습니다.

API Connect를 통해 기업은 API 관리의 최첨단 기술을 사용해 운영할 수 있으며, 이는 시간이 지남에 따라 점점 더 규모가 커지고 복잡해지고 경쟁이 치열해지는 컴퓨팅 환경에서 매우 중요한 역할을 할 것입니다.

작가

Chrystal R. China

Staff Writer, Automation & ITOps

IBM Think

GraphQL과 REST API: 차이점은 무엇인가요?