Rest vs GraphQL 장단점 간단 비교

 API는 서버 - 서버 또는 서버 - 클라이언트, 클라이언트 - 클라이언트 간 정보를 요청하고 전달하는데 목적을 가지고 있는데 목적을 가지고 있습니다. 풀어서 Application Programming Interface 이라고 합니다. 소프트웨어에서는 다양한 곳에서 다양한 뜻으로 사용되지만 해당 글에서는 Backend에서 제공하는 인터페이스에 대해서 이야기하려고 합니다.

 

 해당 글에서는 Rest와 GraphQL의 깊은 이야기는 배제하고 각각의 장단점과 언제 쓰이면 좋을지에 대해 기술합니다. 주관적인 요소가 많이 들어가 있어 상황에 따라 유연하게 사용하시기를 권장드립니다!

 

  Rest API 장점

• 리소스를 중심으로 설계되어 있어 계층구조를 파악하고 연관관계를 알기 쉽습니다.
• 정해진 규칙에 대한 Response만을 담고 있어 정보에 대한 통제력을 유지할 수 있습니다.
• End Point와 규칙만 알고 있다면 모든 플랫폼에서 손쉽게 접근하여 사용이 가능합니다.
• 통신 규약이 명확하여 각 플랫폼간 독립적으로 동작할 수 있습니다.

  Rest API 단점

• 규약을 명확히 전달하기위해 별도의 문서를 제공할 필요성이 있습니다.
• URI에 대한 고민이 많이 필요합니다.
• HTTP 메소드에 제약이 걸려있어 리소스 중심으로 URI를 설계하는데 난이도가 있습니다. 

  GraphQL 장점

• 스키마 정보가 별도로 제공되어 소통에 대한 비용을 절감할 수 있습니다.
• 단일 End Point를 사용하여 다양한 URI를 알 필요가 없습니다.
• 원하는 데이터를 골라 요청할 수 있어서 데이터를 클라이언트에서 주도적으로 사용할 수 있습니다.

  GraphQL 장점

• 데이터에 대한 권한이 클라이언트에 있어 보안적인 요소에서 위험성을 가지고 있습니다.
• 과도한 쿼리 요청으로 내부 성능이 급격히 저하될 가능성이 존재합니다.
• Mutation 오퍼레이션 이름을 명확히 설계할 필요성이 있습니다.
• 각 오퍼레이션에 대한 버전 별 관리가 용이하지 못합니다.

그럼 언제 Rest API를 사용하고 언제 GraphQL을 사용하면 좋을까요?

 

Rest API를 추천하는 경우

 일반적인 어플리케이션에서는 Rest API를 조금 더 추천드리지만 GraphQL도 훌륭한 대안중 하나입니다. 각 API에 대한 독립된 구성을 제어하기 편하며 명확한 Response가 정해져 있기 때문입니다. 

 하지만 만약 Web과 App등 다양한 클라이언트를 동시에 지원하거나 Open API와 같이 불특정 다수가 사용한다면 Rest API를 더 추천하는데, 이유는 Http 규약을 활용하여 어떤 클라이언트등 별도의 설정이나 추가적인 의존성없이 개발이 가능하기 때문입니다.

 
GraphQL을 추천하는 경우

 어플리케이션이 데이터를 읽고 표시해주는 검색에 초점이 맞춰져 있다면 GraphQL을 추천합니다. 원하는 정보를 상황에 따라서 요청하거나 필터링을 걸기 편리합니다. 

 또는 데이터에 대한 변경이 적고 불러오는데 중심이 되어 있는 서비스 또한 GraphQL로 API를 제공할때 유연하게 사용할 수 있습니다.