REST API와 GraphQL의 차이점 알아보기

REST API vs GraphQL API

개발에서 데이터를 전달하고 처리하는 방법은 매우 중요하다.

REST API는 오랜 시간 동안 표준으로 자리 잡아 왔고 GraphQL API의 등장 이후로 해당 방식을 채택하는 기업이 늘고 있다.

 

프로젝트를 진행하다 보면 REST API가 표준으로 자리 잡은 만큼 많이 사용되기 때문에 GraphQL을 활용할 일이 별로 없었다.

기존 시스템과의 호환성 문제나 서버를 새로 개발하거나 변환하는 비용이 들기 때문이라고 생각한다.

실무에서는 아직 접하지 못했지만, 예제 프로젝트에서 사용 전 내용을 다시 정리하기 위해 포스팅해 본다😉

 

 

REST API와 GraphQL의 특징을 요약하면 다음과 같다.

특징	REST API	GraphQL API
데이터 요청 방식	엔드포인트마다 별도의 URL을 사용해 데이터 요청	단일 엔드포인트(/graphql)에서 필요한 데이터를 쿼리로 지정해서 요청
데이터 크기	필요한 데이터 외에도 불필요한 데이터를 함께 반환	요청한 데이터만 반환
API 설계 방식	각 자원(resource)에 대해 엔드포인트를 설계	데이터 타입과 관계(schema)를 정의하고, 클라이언트가 원하는 형태로 요청 가능
유연성	특정 엔드포인트에서 정해진 데이터 구조만 반환	클라이언트가 필요한 데이터 구조를 자유롭게 정의할 수 있음
Over-fetching	데이터가 과도하게 반환되는 경우가 많음 (예: /users 호출 시 모든 유저 데이터 반환)	필요한 데이터만 가져옴 (예: 특정 유저의 이름과 이메일만 요청)
Under-fetching	복잡한 데이터 구조에서는 여러 엔드포인트를 호출해야 함	단일 요청으로 연관된 데이터를 모두 가져올 수 있음
학습 난이도	비교적 쉬움 (기존 HTTP와 유사)	스키마와 쿼리 작성 방법을 익혀야 해서 학습 난이도가 높음

 

 

---

 

REST API

REST API는 각 자원(resource)에 대해 엔드포인트를 설계하는 방식으로 작동한다.

클라이언트는 특정 URL에 HTTP 메서드(GET, POST, PUT, DELETE)를 사용하여 요청을 보내고 데이터를 반환받는다.

 

장점

1. 쉽고 직관적: HTTP 기반이기 때문에 비교적 학습 곡선이 낮고 쉽다.
2. 기존 시스템과 호환: 대부분의 웹 서버 및 클라이언트가 REST를 기본으로 지원한다.
3. 캐싱 지원: 브라우저와 서버 캐싱을 통해 성능 최적화가 가능하다.

단점

1. Over-fetching: 사용자가 필요하지 않은 데이터까지 포함하여 반환될 가능성이 크다.
2. Under-fetching: 복잡한 데이터를 요청할 경우 여러 번의 네트워크 요청이 필요하다.
3. 유연성 부족: 클라이언트는 서버가 제공하는 데이터 구조에 의존해야 한다.

개인적으로 느끼는 부분은 1, 3번 단점의 경우가 프로젝트를 진행하다 보면 자주 발생하는 문제라고 생각한다.

백엔드 개발자에게 요구사항이 미흡하게 전달되거나, 구조 및 디자인의 변화에 맞춰서도 필요한 데이터가 달라질 수도 있기 때문에 프론트, 백 모두 재수정을 해야 하는 불편함을 종종 느꼈다.

 

REST API가 적합한 경우는 다음과 같다.

• 단순한 CRUD 애플리케이션에서 기본적인 데이터 전달이 필요한 경우
• 기존 RESTful 서비스와의 호환성이 중요한 경우
• 캐싱이 중요한 애플리케이션(예: 뉴스 피드, 블로그 등)

 

---

 

GraphQL API

GraphQL은 2012년에 Facebook이 개발하여 2015년에 오픈소스로 공개된 쿼리 언어로, 클라이언트가 필요한 데이터만 요청할 수 있도록 설계되었다. 단일 엔드포인트(/graphql)에서 쿼리를 통해 데이터 요청이 이루어지며 데이터 타입과 관계를 정의하는 스키마(schema)를 기반으로 동작한다.

 

장점

1. 유연성: 클라이언트가 필요한 데이터의 형태를 자유롭게 정의할 수 있다.
2. Over-fetching과 Under-fetching 해결: 필요한 데이터만 요청하며 한 번의 요청으로 여러 연관 데이터를 가져올 수 있다.
3. Self-documenting: GraphQL 스키마는 자동으로 API 문서를 제공한다.

단점

1. 학습 난이도: REST보다 학습 난이도가 높고, 쿼리와 스키마 설계가 필요하다.
2. 캐싱 어려움: REST처럼 URL 기반 캐싱이 어렵고, 캐싱 전략을 직접 구현해야 한다.
3. 복잡한 설정: GraphQL 서버를 설정하는 과정이 REST보다 복잡할 수 있다.

 

추가적으로 REST는 Postman, Swagger 등의 툴을 통해 쉽게 테스트하고 디버깅할 수 있지만, GraphQL은 GraphQL Playground나 Apollo Studio를 따로 사용해야 한다는 단점이 있다.

 

 

GraphQL API가 적합한 경우는 다음과 같다.

• 클라이언트가 데이터를 유연하게 요청해야 하는 복잡한 애플리케이션
• 여러 자원 간의 관계가 깊고, 연관 데이터를 한 번에 가져와야 하는 경우
• 모바일 애플리케이션과 같이 네트워크 요청을 최소화해야 하는 경우

 

---

 

 

 

GraphQL은 REST의 한계를 보완하는 강력한 도구이지만, 한국의 현업에서는 REST API가 여전히 주요 방식으로 사용된다고 생각한다. 보통 스타트업이나 빠르게 결과물을 만들어야 하는 프로젝트에서는 REST가 더 직관적이고 빠르게 구축할 수 있기 때문에 더 많이 사용되고 있다.

하지만 GraphQL 역시 인기를 얻고 있는 것으로 보이는데 보통 대규모 데이터가 연관된 서비스나 복잡한 클라이언트 요구사항이 있는 경우이다. 한국에서도 일부 기업(예: 카카오, 네이버, 당근, 모두싸인 등 / GPT 피셜ㅎ)에서는 GraphQL을 도입해 유연한 데이터 요청 방식과 API 관리의 효율성을 추구하고 있다고 한다.

 

현업에서 REST API를 주로 사용하더라도 GraphQL의 개념과 장단점을 익혀두면 추후에 GraphQL을 도입할 때 학습 시간을 줄일 수 있지 않을까 싶다!