Server API (혹은 Server-side web API) 는 적절한 요청을 하였을 때,
그에 맞는 응답을 되돌려주는 창구 (Endpoint) 를 Web 을 통해 노출한 것을 말한다.
이 Server API 를 만드는 방법론 중 하나로 REST 라는 것이 있으며,
이 방법론은 많은 Server API 들을 구성하기 위해 사용되어왔고, 또 현재도 많이 사용되고 있다.
예시로 어떤 API 가 Community site 용 API 이며,
이 API 를 사용해 사용자들이 글을 작성/수정/삭제 할 수 있고,
각 글에 댓글을 작성/수정/삭제할 수 있다고 해보자.
이때, API 의 Endpoint 를 다음과 같이 구성하면 REST 의 조건을 간략히는 만족하게 된다.
글 관련 API = /posts
글 작성 = POST /posts
글 수정 = PATCH /posts/[postid]
글 삭제 = DELETE /posts/[postid]
댓글 관련 API = /posts/[postid]/comments
댓글 작성 = POST /posts/[postid]/comments
댓글 수정 = PATCH /posts/[postid]/comments/[commentid]
댓글 삭제 = DELETE /posts/[postid]/comments/[commentid]
REST API는 URL, METHOD등을 조합하기 때문에 다양한 Endpoint가 존재 하는 반면, gql은 단 하나의 Endpoint가 존재 한다. 또한, gql API에서는 불러오는 데이터의 종류를 쿼리 조합을 통해서 결정 한다. 예를 들면, REST API에서는 각 Endpoint마다 데이터베이스 SQL 쿼리가 달라지는 반면, gql API는 gql 스키마의 타입마다 데이터베이스 SQL 쿼리가 달라진다.
그렇다면 GraphQL 과 RESTful 중 어떤 것을 선택해서 사용해야하는가?
다음과 같은 기준으로 선택하면 될 것이다.
제가 생각하는 REST API를 사용하는 이유는, 비즈니스의 복잡성 때문에 분산 환경 시스템이 점점 많아지고 있고, 모바일 시대가 대두되는 요즘에 기존의 HTTP 방식으로는 한계가 분명히 존재하기 때문이라고 생각해요!
즉, API가 필요해진 것이고 그 중에서 REST 방식을 택한 가장 큰 이유는, 별도의 비용 없이 HTTP라는 프로토콜을 이용해서 통신이 가능하다는 장점이 있기 때문이라고도 생각합니다.
사실 예전 웹을 경험해보셨다면, GET, POST만가지고 DB조작을 했던 때도 있고, 지금도 이렇게 하고 있는 Legacy들이 많을거에요.
그리고, REST API의 장점은 사람이 읽기 편함도 있다고 생각합니다. GET, POST, PUT, DELETE, PATCH 뒤에 자원 명이 들어가는 단순한 구조에서 오는 장점인데요. 엔드포인트가 여러개라는 말은, 클라이언트에서는 비즈니스 로직에 신경쓸 일이 줄어든다라고 보시면 될 것 같아요.
반면에, GraphQL은 요청을 직접 할 수 있으니, 구현의 자유도가 좀 더 늘어난다는 점이 있을 것 같고, 단점으로는 FE 작업의 복잡성이 늘어나지 않을까? 라는 생각이 드네요. (물론 사용해보지는 않았습니다.)