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

GraphQL과 REST는 모두 클라이언트-서버 모델에서 서로 다른 서비스 또는 애플리케이션 간에 데이터를 교환할 수 있는 널리 사용되는 API 아키텍처 스타일입니다.

API는 다음과 같은 데이터 액세스 및 데이터 작업을 지원합니다.

1. 클라이언트가 서버의 엔드포인트 또는 여러 엔드포인트에 API 요청을 전송
2. 서버가 데이터, 데이터 상태 또는 오류 코드가 포함된 응답을 제공

REST 및 GraphQL을 사용하면 API를 통해 별도의 애플리케이션, 서비스 또는 모듈에서 데이터를 생성, 수정, 업데이트 및 삭제할 수 있습니다. REST를 사용하여 개발된 API를 RESTful API 또는 REST API라고 합니다. GraphQL로 개발된 API는 그냥 GraphQL API라고 합니다.

프런트엔드 및 백엔드 팀은 이러한 API 아키텍처를 사용하여 모듈식 애플리케이션 및 접근성이 뛰어난 애플리케이션을 만듭니다. API 아키텍처를 사용하면 시스템을 안전하고 모듈화되고 확장 가능한 상태로 유지할 수 있습니다. 또한 시스템의 성능이 향상되고 다른 시스템과의 통합이 더 쉬워집니다.

다음으로 GraphQL과 REST의 다른 유사점을 몇 가지 살펴보겠습니다.

API에 대해 읽어보기 »

아키텍처

REST와 GraphQL 모두 몇 가지 일반적인 API 아키텍처 원칙을 구현합니다. 예를 들어 이 둘의 공통적인 원칙은 다음과 같습니다.

• 둘 다 상태를 저장하지 않으므로 서버가 요청 간에 응답 기록을 저장하지 않습니다.
• 둘 다 클라이언트-서버 모델을 사용하므로 단일 클라이언트에서 요청하면 단일 서버에서 응답합니다.
• 둘 다 기반 통신 프로토콜인 HTTP를 기반으로 합니다.

리소스 기반 설계

REST와 GraphQL은 모두 리소스를 중심으로 데이터 교환을 설계합니다. 리소스는 클라이언트가 API를 통해 액세스하고 조작할 수 있는 모든 데이터 또는 객체를 말합니다. 각 리소스마다, 고유한 식별자(URI)와 클라이언트가 해당 리소스에 대해 수행할 수 있는 작업 세트(HTTP 메서드)가 있습니다.

사용자가 게시물을 만들고 관리하는 소셜 미디어 API를 예를 들어 보겠습니다. 리소스 기반 API에서 게시물은 리소스가 됩니다. 게시물에는 고유한 식별자가 있습니다(예: /posts/1234). 또한 REST에서 게시물을 검색하는 GET이나 GraphQL에서 게시물을 검색하는 query와 같은 일련의 작업이 있습니다.

데이터 교환

REST와 GraphQL 모두 유사한 데이터 형식을 지원합니다.

JSON은 모든 언어, 플랫폼 및 시스템이 인식하는 가장 널리 사용되는 데이터 교환 형식입니다. 서버는 JSON 데이터를 클라이언트에 반환합니다. XML 및 HTML을 비롯한 다른 데이터 형식을 사용할 수 있지만 일반적으로 사용되지는 않습니다.

마찬가지로, REST와 GraphQL은 모두 캐싱을 지원합니다. 따라서 클라이언트와 서버는 자주 액세스하는 데이터를 캐싱하여 통신 속도를 높일 수 있습니다.

JSON에 대해 읽어보기 »

언어 및 데이터베이스 중립성

GraphQL과 REST API 모두 클라이언트 측과 서버 측의 모든 데이터베이스 구조 및 프로그래밍 언어를 지원합니다. 따라서 모든 애플리케이션과의 상호 운용성이 뛰어납니다.

REST API는 애플리케이션 통신을 위한 아키텍처 개념입니다. 반면, GraphQL은 사양, API 쿼리 언어 및 도구 세트입니다. GraphQL은 HTTP를 사용하여 단일 엔드포인트에서 작동합니다.

또한 REST는 새로운 API를 만드는 데 더 중점을 두고 개발되어 왔습니다. 반면, GraphQL은 API 성능과 유연성에 중점을 두었습니다.

다음으로 몇 가지 차이점을 더 살펴보겠습니다.

클라이언트 측 요청

REST 요청 작동에 사용되는 요소는 다음과 같습니다. 

• 동작을 결정하는 HTTP 동사
• HTTP 동사를 작동시킬 리소스를 식별하는 URL
• 기존 서버 측 리소스 내에서 객체를 생성하거나 수정하려는 경우 구문 분석할 파라미터 및 값

예를 들어 리소스에서 읽기 전용 데이터를 가져오려면 GET을 사용하고, 새 리소스 항목을 추가하려면 POST를 사용하며, 리소스를 업데이트하려면 PUT을 사용합니다.

이와 대조적으로 GraphQL 요청에 사용되는 요소는 다음과 같습니다.

• 읽기 전용 데이터를 가져오기 위한 쿼리
• 데이터 수정을 위한 변형
• 이벤트 기반 또는 스트리밍 데이터 업데이트 수신을 위한 구독

데이터 형식은 서버 측 스키마와 일치하는 객체 및 필드를 포함하여 서버가 데이터를 반환하는 방법을 설명합니다. 새 데이터를 입력할 수도 있습니다. 내부적으로 GraphQL은 모든 클라이언트 요청을 POST HTTP 요청으로 전송합니다.

클라이언트에 반환되는 데이터

REST 아키텍처에서는 서버가 지정한 전체 리소스 구조로, 서버에서 클라이언트로 데이터가 반환됩니다. 다음 예제는 REST 및 GraphQL에서 반환되는 데이터를 보여줍니다.

REST에서 반환되는 데이터의 예

REST에서 GET /posts는 다음을 반환합니다.

[

  {

    "id": 1,

    "title": "First Post",

    "content": "This is the content of the first post."

  },

  {

    "id": 2,

    "title": "Second Post",

    "content": "This is the content of the second post."

  },

  {

    "id": 3,

    "title": "Third Post",

    "content": "This is the content of the third post."

  }

]

GraphQL에서 반환되는 데이터의 예

GraphQL을 사용할 경우 클라이언트가 제공한 구조에 지정된 데이터만 반환됩니다.

GET /graphql?query{post(id: 1) {id title content}}는 첫 번째 게시물만 반환합니다.

{

  "data": {

    "posts": [

      {

        "id": "1",

        "title": "First Post",

        "content": "This is the content of the first post."

      },

]}}

서버 측 스키마

GraphQL은 서버 측 스키마를 사용하여 데이터 및 데이터 서비스를 정의하는데, 이는 REST API와 다릅니다.

GraphQL 스키마 정의 언어로 작성된 스키마에는 다음과 같은 세부 정보가 포함됩니다.

• 각 객체에 속하는 객체 유형 및 필드
• 각 필드에 대한 작업을 정의하는 서버 측 Resolver 함수

스키마는 시스템에서 사용 가능한 모든 데이터와 클라이언트가 해당 데이터에 액세스하거나 수정할 수 있는 방법을 설명하는 유형을 명시적으로 정의합니다. 

반면, REST API에는 서버 측 스키마가 필요하지 않습니다. 하지만 효율적인 API 설계, 문서화 및 클라이언트 개발을 위해 선택적으로 정의할 수도 있습니다. 

버전 관리

API가 발전함에 따라 데이터 구조와 작업이 변경될 수 있습니다. 이러한 변경 사항을 인식하지 못하는 클라이언트의 경우 시스템이 손상되거나 알 수 없는 오류가 발생할 수 있습니다.

REST API에는 이 문제를 해결하기 위한 URL 버전 관리 기능이 포함되는 경우가 많습니다(예: https://example.com/api/v1/person/12341). 하지만 버전 관리는 필수가 아니며 이로 인해 오류가 발생할 수 있습니다. 

GraphQL에는 이전 버전 API와의 호환성이 필요합니다. 따라서 삭제된 필드로 인해 오류 메시지가 반환되거나, 더 이상 사용되지 않는 태그가 있는 필드로 인해 경고가 반환될 수 있습니다.

오류 처리

GraphQL은 엄격하게 형식이 지정되는 API 아키텍처이므로 스키마의 데이터, 구조 및 데이터 작업에 대한 자세한 설명이 필요합니다. 스키마의 세부 수준 덕분에 시스템은 요청 오류를 자동으로 식별하고 유용한 오류 메시지를 제공할 수 있습니다. 

REST API는 형식이 약하게 지정되므로 주변 코드에 오류 처리 기능을 빌드해야 합니다. 예를 들어 PUT 요청에서 숫자 값을 정수가 아닌 텍스트로 구문 분석하는 경우 시스템이 오류를 자동으로 식별하지 않습니다.

전체 재작성을 수행하지 않고도 RESTful API를 GraphQL API로 업그레이드할 수 있습니다.

이 프로세스의 개요는 다음과 같습니다.

1. RESTful API의 데이터 모델을 파악합니다. 이렇게 하려면 각 URL 리소스의 데이터 형태를 살펴봅니다.
2. 데이터 모델에서 GraphQL 스키마를 작성합니다.
3. 클라이언트가 데이터에 대해 수행하는 작업을 결정하고 스키마에 포함합니다.
4. 스키마의 각 필드에 대한 서버 측 코드에서 Resolver 함수를 빌드합니다.
5. Resolver와 스키마를 사용하여 GraphQL 서버를 생성합니다.

그러면 클라이언트는 GraphQL 또는 REST를 사용하여 API와 통신할 수 있습니다.

GraphQL Resolver 빌드 방법 읽어보기 »

Amazon Web Services(AWS)는 더 나은 관리형 API를 구축하고 제공할 수 있도록 도와줍니다.

AWS AppSync는 서버리스 GraphQL 및 게시-구독(pub/sub) API를 생성합니다. 이 API는 단일 엔드포인트를 통해 애플리케이션 개발을 간소화하여 데이터를 안전하게 쿼리, 업데이트 또는 게시합니다.

AWS AppSync를 사용하면 클라이언트가 다음을 수행하는 API를 생성할 수 있습니다.

• 단일 네트워크 호출로 SQL, NoSQL, 검색 데이터, REST 엔드포인트, 마이크로서비스 등의 여러 데이터 소스와 상호 작용합니다.
• 모바일 및 웹 애플리케이션과 클라우드 간에 데이터를 자동으로 동기화합니다.
• 백엔드에서 연결된 클라이언트로 또는 연결된 클라이언트 간에 데이터를 브로드캐스트합니다.
• 사물 인터넷(IoT) 데이터에 액세스하여 모바일 또는 웹 애플리케이션에서 실시간 대시보드를 구축합니다.

마찬가지로, Amazon API Gateway는 어떤 규모에서든 API를 손쉽게 생성, 게시, 유지 관리, 모니터링 및 보안 유지할 수 있도록 하는 완전관리형 서비스입니다.

API Gateway를 사용하여 얻을 수 있는 이점은 다음과 같습니다.

• API 요청 및 응답 모두에 대해 사용자에게 고속 성능을 제공합니다.
• API에 대한 액세스 권한을 부여합니다.
• 동일한 API의 여러 버전을 동시에 실행하여 새로운 버전을 빠르게 반복, 테스트 및 출시합니다.
• API 호출, 데이터 지연 시간 및 오류율에 대한 성능 지표 및 정보를 모니터링합니다.

지금 계정을 만들어 AWS에서 GraphQL과 REST를 시작하세요.