개요

GraphQL과 REST API의 핵심 차이점은 GraphQL은 사양, 쿼리 언어인 반면

REST는 네트워크 기반 소프트웨어를 위한 아키텍처 개념이라는 것입니다.

REST API의 후속으로 GraphQL이 탄력을 받고 있습니다. 그러나 이것이 항상 "대체"인 것은 아니며, GraphQL을 선택하기 위해서는 몇 가지 고려 사항이 수반됩니다.

REST는 전통적으로 "즉시 사용"할 때 여러 개의 네트워크 요청과 데이터 오버페치 등의 제한이 있었습니다. 이를 극복하기 위해 Facebook은 API를 위한 오픈 소스 데이터 쿼리 및 조작 언어로 GraphQL을 개발했습니다.

GraphQL은 데이터를 요청하기 위한 구문이며 필요한 사항을 정확하게 지정할 수 있습니다.

사용 사례에 따라 GraphQL 또는 REST API 또는 이 둘의 조합을 선택해야 합니다. 보다 정확한 결정을 위해 REST와 GraphQL을 살펴보고 GraphQL을 선택한 몇 가지 이유를 알아보겠습니다.

REST APIs

REST API란 무엇인가?

REST(Representational State Transfer)는 웹 서비스를 개발할 때 일련의 제약 조건을 준수하는 아키텍처 스타일입니다. SOAP API의 후속으로 도입되었습니다. REST 또는 RESTful AP는 REST 표준을 따르는 웹 서비스 API입니다. SOAP와 달리 REST API는 XML 형식으로 제한되지 않으며 필요한 항목에 따라 여러 데이터 형식을 반환할 수 있습니다. REST API에서 지원되는 데이터 형식에는 JSON, XML 및 YAML이 있습니다.

클라이언트가 REST API를 호출할 때 서버는 표준화된 표현으로 리소스를 전송합니다. 요청한 원본에 대한 정보를 반환하는 방식으로 작동하며, 해석 가능한 형식으로 변환됩니다.

REST API를 사용하면 클라이언트 측에서 서버로 수정 및 추가할 수 있으며, GraphQL Mutations와 몇 가지 유사점을 찾을 수 있습니다. 여기서 자세히 살펴보겠습니다.

REST APIs의 작동

REST 요청은 엔드포인트, HTTP 메서드, 헤더 및 본문으로 구성됩니다.

엔드포인트에는 온라인에서 리소스를 식별하는 데 도움이 되는 URI(Uniform Resource Identifier)가 포함되어 있습니다.

HTTP 메서드는 서버로 전송되는 요청 유형을 설명합니다. 다음과 같습니다.

GET 데이터를 가져옵니다.
POST 새로운 데이터를 생성 합니다
PUT 업데이트/변경 작업을 합니다.
PATCH 소스를 수정합니다
DELETE 데이터를 지웁니다.

RESTful API는 데이터로 작업할 때 HTTP 메서드를 사용하여 CRUD(Create, Read, Update 및 Delete) 작업을 수행합니다.

헤더는 캐시, AB 테스트, 인증 등과 같은 목적으로 클라이언트 및 서버에 정보를 제공합니다.

본문에는 요청의 페이로드와 같이 클라이언트가 서버로 보내려는 정보가 들어 있습니다.

GraphQL APIs

GraphQL이란 무엇인가?

GraphQL은 API용 오픈 소스 데이터 쿼리 및 조작 언어이며, 기존 데이터로 쿼리를 수행하기 위한 런타임입니다. 주로 GraphQL Foundation을 통해 유지 관리 및 개발된 GraphQL은 Twitter, Expedia, Shopify 및 GraphCMS와 같은 조직에서 다양한 업종과 사용 사례에 놀라운 채택을 이루어 왔습니다.

GraphQL API의 장점들

이제 GraphQL이 돋보이는 몇 가지 기본적인 이점을 살펴보겠습니다.

Data Fetching

REST의 가장 일반적인 한계 중 하나는 오버페치 및 언더페치입니다. 클라이언트가 데이터를 다운로드할 수 있는 유일한 방법은 고정 데이터 세트를 반환하는 엔드포인트를 누르는 것이기 때문에 이 문제가 발생합니다. 고객에게 정확한 데이터 요구를 제공할 수 있는 방식으로 API를 설계하는 것은 매우 어렵습니다.

오버패치는 필요한 것보다 더 많은 정보를 얻는 것을 의미합니다. 예를 들어, 엔드포인트에서 레스토랑에서 사용할 수 있는 버거의 데이터를 보유하고 있다면 /burgers 엔드포인트를 눌러 원하는 이름만 얻는 대신 가격, 재료, 칼로리 등 엔드포인트가 제공하는 모든 정보를 얻을 수 있습니다. GraphQL을 사용하면 쿼리에서 원하는 내용을 받아쓰기만 하면 됩니다.

{
  burgers {
    name
  }
}

응답에는 엔드포인트가 제공할 수 있는 다른 정보가 포함되지 않으므로 요청한 내용에 따라 작업할 수 있는 예측 가능한 데이터셋이 제공됩니다.

Schema 와 Type 의 안정성

GraphQL은 강력한 유형의 시스템을 사용하여 API의 기능을 정의합니다. API에 표시되는 모든 유형은 GraphQL Schema Definition Language(SDL) 및/또는 코드 우선 언어를 사용하여 스키마에 기록됩니다.

프런트엔드 팀은 이제 API 설계에 대한 백엔드 팀의 변경 사항이 있을 경우 프런트엔드로부터 쿼리할 때 즉각적인 피드백을 받을 수 있으므로 입력된 GraphQL API로 작업할 수 있습니다.

GraphQL Code Generator와 같은 인기 있는 도구는 코드베이스 GraphQL 쿼리 파일에서 직접 쿼리 및 돌연변이에 대한 모든 코드를 자동으로 빌드할 수 있습니다. 이를 통해 개발 속도를 높이고 생산 오류를 방지할 수 있습니다.

개발 생산성 향상

REST API의 일반적인 패턴은 앱 내부에 있는 보기(예: /menu, /price, /images 등)에 따라 엔드포인트를 구성하는 것입니다. 이 기능은 클라이언트가 해당 엔드포인트에 액세스하기만 하면 특정 보기에 필요한 모든 정보를 얻을 수 있으므로 편리합니다.

이 접근 방식의 단점은 빠른 반복을 허용하지 않는다는 것입니다. UI를 변경할 때마다 이전보다 더 많은(또는 더 적은) 데이터가 필요할 위험이 있습니다.

따라서 백엔드는 이러한 새로운 데이터 요구사항을 고려하여 조정되어야 하며, 이로 인해 생산성이 저하되고 제품 개발 프로세스가 느려집니다.

GraphQL의 유연한 특성으로 서버에 대한 추가 작업 없이 클라이언트 측에서 변경할 수 있습니다. 고객은 정확한 데이터 요구사항을 지정할 수 있으므로 프런트 엔드의 설계 및 데이터가 변경될 때 백엔드를 조정할 필요가 없습니다.

Schema 연결

주요 차이점은 스키마를 연결하는 기능입니다. GraphQL은 여러 스키마를 단일 스키마로 결합하여 클라이언트가 액세스할 수 있도록 할 수 있습니다. 예를 들어, 특정 메뉴의 세부 정보와 항목의 영양 정보를 서로 다른 소스에서 단일 스키마로 가져와 버거 API와 영양 API의 스키마를 병합하는 것입니다.

{
  burgers(where: { name: "cheeseburger"})
  # from Menu endpoint
  name 
  description 
  price 
  # from Nutrition endpoint
  calories 
  carbohydrates  
  # from Restaurant endpoint
  inStock 
}

GraphCMS에서 Schema Stitching의 다음 단계는 GraphQL 및 REST API를 단일 GraphQL endpoint 로 통합하는 기능입니다.

GraphQL vs. REST

GraphQL과 REST API의 핵심 차이점은 GraphQL은 사양, 쿼리 언어인 반면 REST는 네트워크 기반 소프트웨어를 위한 아키텍처 개념이라는 것입니다.

GraphQL은 강력한 타이핑과 스키마 유형 및 설명에 기반한 자체 문서화 및 코드 생성 도구와 통합되어 개발 시간을 단축할 수 있습니다.

가장 잘 알려진 차이점 중 하나인 질의에 대한 예상 응답의 차이를 매우 간단한 용어로 생각할 때, 우리는 햄버거를 주문하는 과정을 생각할 수 있습니다. GraphQL 버거 밈은 한동안 존재했지만, 여전히 개념을 쉽게 파악할 수 있도록 해 줍니다.

여러분이 버거 식당에 들어가서 치즈버거를 주문한다고 상상해 보세요. 몇 번을 주문하든(RESTful API라고 함), 매번 더블 치즈버거에 들어가는 모든 재료를 얻을 수 있습니다. 항상 동일한 모양과 크기(RESTful 응답으로 반환됨)가 됩니다.

https://api.com/cheeseburger/

GraphQL을 사용하면 원하는 치즈버거를 정확하게 설명함으로써 "네 마음대로" 할 수 있습니다. 이제 치즈버거(응답)를 빵 위에 올리고 패티, 피클, 양파, 치즈를 맨 아래 빵 없이 먹을 수 있습니다.

query getCheeseburger ($vegan: Boolean) {
  cheeseburger {
    bun
    patty
    pickle
    onion
    cheese @skip(if: $vegan)
  }
}

그래프QL 응답은 사용자가 설명하는 대로 형상화되고 크기가 지정됩니다. 당신의 대답은 당신이 원하거나 문의한 것과 똑같습니다.

REST API는 네트워크 기반 소프트웨어를 위한 "아키텍처 개념"입니다. 반면, GraphQL은 단일 엔드포인트에서 작동하는 쿼리 언어이자 도구 세트입니다. 또한 지난 몇 년 동안 REST는 새로운 API를 만드는 데 사용되었으며, GraphQL은 성능과 유연성을 최적화하는 데 중점을 두고 있습니다.

REST를 사용할 때 완전한 "데이터 세트"의 응답을 받을 수 있습니다. x개의 객체에서 정보를 요청하려면 x개의 REST API 요청을 수행해야 합니다. 메뉴 웹 사이트의 제품 정보를 요청하는 경우 다음과 같은 방식으로 요청을 구성할 수 있습니다.

요청 /menu으로 버거 이름, 설명, 재료 등 요청
다른 요청 /prices에서 해당 메뉴와 관련된 가격 요청
/images 에서 다른 데이터 세트의 메뉴 샷 요청
... 등등

반대로, 특정 엔드포인트에서 일부 정보를 수집하려는 경우 REST API가 반환하는 필드를 제한할 수 없습니다. 추가 구성 없이 REST API를 사용할 경우 항상 전체 데이터 세트 또는 오버페치를 얻을 수 있습니다.

GraphQL은 쿼리 언어를 사용하여 요청을 여러 개체에서 각 엔터티 내의 특정 필드에 이르기까지 정확히 필요한 대로 조정합니다. GraphQL은 x개의 엔드포인트를 차지하며, 이 정보로 많은 것을 할 수 있습니다. 하지만 먼저 원하는 것을 말해야 합니다.

동일한 예를 사용하여 요청은 동일한 엔드포인트에서 menuItem, menuEnders, menuImage 및 menuPrice를 한 요청 내에서 가져오기만 하면 됩니다. 데이터베이스 내의 다른 모든 콘텐츠는 반환되지 않으므로 오버페치 문제는 문제가 되지 않습니다.

이전에 강조했던 버거 비유와 매우 유사합니다. REST는 레스토랑의 메뉴에 있는 치즈 버거를 가져오지만 GraphQL은 원하는 양을 정확하게 얻기 위해 해당 버거를 수정할 수 있습니다.

REST를 사용하거나 REST를 사용하여 GraphQL을 선택하는 것은 매우 주관적인 결정으로, 사용 사례에 크게 영향을 받습니다. REST의 대안으로도, 대체물로도 GraphQL을 고려하지 않는 것이 중요합니다. 이러한 결정을 간소화하기 위해 다음과 같은 몇 가지 주요 차별화 요소가 있습니다.

GraphQL	REST
API 통합 시 일반적인 문제를 해결하기 위한 쿼리 언어	API 설계를 위한 기존 표준으로 크게 간주되는 아키텍처 스타일
노출된 서비스의 전체 기능을 제공하는 단일 엔드포인트를 사용하여 HTTP를 통해 배포	각각이 단일 리소스를 노출하는 URL 집합을 통해 배포됨
클라이언트 중심 아키텍처 사용	서버 중심 아키텍처 사용
내장된 캐싱 메커니즘 부족	자동으로 캐싱 사용
API 버전 관리가 필요하지 않음	여러 API 버전 지원
JSON의 응답 출력	일반적으로 XML, JSON 및 YAML로 된 응답 출력
유형 안전성 및 자동 생성 문서 제공	유형 안전 또는 자동 생성 문서를 제공하지 않습니다.
스키마 스티칭 및 원격 데이터 가져오기 허용	여러 엔드포인트로 작업을 단순화하려면 값비싼 맞춤형 미들웨어가 필요합니다.

한국그리고사람

GraphQL vs REST API 차이점을 알아봅시다.

개요