05. Rest-api와 Graphql-api

 백엔드에서 프론트, 데이터베이스, 혹은 사용자까지 통신하기 위해서 API를 만든다. API는 일종의 통신매개체로 볼 수 있는데 프론트에서 "~~한 정보를 줘!" 하면 ~~에 해당하는 정보를 데이터베이스에서 꺼내오고, 이를 API라는 매게체를 통해서 프론트로 전달해 준다. 사실 이 개념을 이해하는것이 말로는 쉬웠는데 막상 코드를 보니 말처럼 간단한 과정이 아니였다. API를 만드는 것은 백엔드의 핵심적인 역할인데 그럼 이 API에는 어떤종류가 있을까? 요즘 가장 많이 사용하는 API에는 REST-API와 GRAPHQL-API가 있다. 이 둘의 장단점과 차이점을 정리해보자

---

REST-API

 나는 기본적으로 어떤 개념을 공부할 때 그 개념의 이름이 갖는 의미를 먼저 찾아본다. 이름에는 그 개념의 가장 핵심적인 기능이 담겨있다고 생각하기 때문이다. 따라서 REST-API의 REST가 무엇인지 먼저 찾아보았다. REST는 Representational State Transfer의 약자라고 한다. 이를 직역해보자면 대표적인 상태의 이전? 이라고 두루뭉실하고 잘 이해가 가지 않는다. 무언가의 상태를 전송해준다는 개념인 것 같다. REST는 쉽게 말해 하나의 소프트웨어 프로그램 아키텍처 형식이다. 즉 해당 자원을 이름으로 구분을 하고 그 자원의 정보를 주고받는 모든 행위를 일컫는다고 볼 수 있다. 여기서 자원은 HTTP의 URL을 통해 명시하고 자원에 대한 상태는 POST, GET, PUT, DELETE를 통해 전달한다. 다른 아키텍처에 비해 구현이 매우 쉽고 stateless한 특성을 지니기에 입력받은 요청에 대한 상태만 처리해 주면 되어 간단하다. 이를 직접 확인해 보기 위해서 postman이라는 사이트를 통해 요청을 보내보았는데 실제로 endpoint를 잘 맞춰주고 req,res를 통해 서로 백엔드와 프론트간의 통신을 해주니 쉽게 데이터가 전송되는것을 확인할 수 있었다. 내가 경험한 rest-api의 특징 외에 다른 사람들은 어떻게 평가하는지 궁금해서 장,단점을 검색해 보았더니 공통적으로 나오는 결과들은 다음과 같았다.

 

• 장점

 - HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용할 수 있다.

 - REST API 메시지가 의도하는 바를 명확하게 나타내므로 의도하는 바를 쉽게 파악할 수 있다.

 - 서버와 클라이언트의 역할을 명확하게 분리한다.

 - 여러 가지 서비스 디자인에서 생길 수 있는 문제를 최소화한다.

 

• 단점

 - 표준이 존재하지 않아 정의가 필요하다.

 - 사용할 수 있는 메소드가 4가지밖에 없다.

 - HTTP METHOD 형태가 제한적이다.

 

여기서 내가 생각하는 대표적인 장 단점은 밑줄친 부분이다. 확실히 단어가 딱  POST, GET, PATCH 등과같이 직접적이기 때문에 어떤 동작을 수행하도록 하기 편리했다. 또한 endpoint만 잘 맞춘다면 쉽게 결과를 확인하기도 편리했다. 하지만 반대로 그점이 단점이 될 때도 있었다. 한정된 메소드로 다양한 동작을 수행하려 하니 마치 알고리즘 테스트를 for문 if문 만으로 푸는 느낌? 물론 그것만으로도 거의 많은 문제들을 풀 수는 있지만 매서드를 활용하면 더 간결하고 편하게 짤 수 있었던 것 처럼 rest-api의 http method도 좀더 다양하면 더 많은 일을 할 수 있지 않을까 생각해본다.

 

GRAPHQL-API

 Graphql은 2012년에 미국의 유명한 IT대기업 Facebook에서 도입된 방식으로 서버와 클라이언트간에 데이터를 가져오고 조작하기 위해 도입된 쿼리 언어이다. 실제로 공개된것은 2015년이라고 하는데 이는 주로 REST방식에서의 문제점을 보완하며 나왔다고 한다. 이는 REST에 비해 보다 더 체계적으로 요청과 응답에 접근하는 방식이다. 한마디로 상대적으로 표준이 모호하고 유연하지 못한 REST방식에 비해 Graphql은 더 효율적이고 빠르게 변화하는 클라이언트의 요구사항에 만족하도록 유연하게 개발되었다. 쉬운 예를 들어보면 페이스북이 너무 커져버려서 데이터를 모두 가져와서 그중 필요한 정보만 사용하는것이 더이상 불가능해지자 애초에 조회할 때 부터 본인들이 필요로 하는 정보만 쏙 빼오기 위해 개발자들을 갈아넣어 만든 언어라고 보면 된다. 이때 요구사항을 쿼리형식으로 graphql서버로 보내고 그 서버는 요구 사항에 충족되는 정보를 JSON형태로 응답한다. REST에서는 그 정보를 가져오기 위해 그 정보를 포함하고 있는 상위의 모든 정보를 싹다 가져오고 그중에서 골라서 건내주기 때문에 상당히 비효율적이다. 하여튼 미국의 대기업은 역시 대단하다. 그렇다면 단순히 그 이유만으로 그동안 사용하던 REST 싹다 버리고 Graphql로 갈아탈만한 것일까? 나는 사실 그래도 무방할 정도로 그 핵심적인 기능이 대단하다고 생각한다. 왜냐면 그렇게 원하는 정보만 불러올 수 있다는 것은 원하는 정보로 분석과 모니터링 요즘 유행하는 AI까지 다룰수 있지 않을까 하는 이유에서다. 그쪽 분야에 대해 잘 아는것은 아니지만 결국 빅데이터, AI등도 데이터를 다루고 분석하는 것이니까 데이터를 얼마나 효율적으로 가져오느냐는 그들에게 굉장히 민감한 문제이지 않을까 생각한다. 그럼 Graphql의 대표적인 장단점은 무엇이 있을까?

 

• 장점

 - 하나의 Endpoint를 지니므로 요청을 보낼때 정해진 한 군데로만 요청을 보내기 때문에 유지보수가 용이하다.

 - 기존의 REST 를 사용하면 정보를 가져오는것이 비효율적이였으나(overfetching) Graphql은 원하는 데이터만 받아올 수 있다.

 - rest는 운영체제마다 다른 api를 각각 구현해야 했지만 Graphql은 표준화된 쿼리 언어로 기종에 상관없이 동작가능하다.

 

• 단점

 - REST에서 구현하는 것보다 Graphql로 단순화된 캐시를 구현하는 것이 더 복잡하다. REST API에서는 URL로 리소스에 엑세스하지만 Graphql에서는 동일한 엔티티에서 작동하더라도 각 쿼리가 다를수 있기 때문에 다소 복잡하다

 - REST API에서는 하루에 이정도의 요청만 허용하도록 지정하는 것이 가능한데 Graphql에서는 이런 유형의 명령문을 지정하기 어렵다.

 

GraphQL Advantages and Disadvantages - javatpoint

출처: https://www.javatpoint.com/graphql-advantages-and-disadvantages

 

 사실 Graphql같은 경우는 아직 많이 사용해보지 않아서 크게 단점으로 와닿는 것이 개인적으로는 없었지만 찾아보니 위와같은 점을 대표적으로 꼽는 것 같았다 이외에도 쿼리의 복잡성과 재귀적인 쿼리가 불가능하다는 말들도 많이 있었지만 내가 아직 이해하기 어려운 말들 같아서 좀 더 공부해봐야겠다! 배워도 배워도 끝이 없는 세상이다. 오히려좋아