Server API
클라이언트가 어떤 요청을 하였을때 그에 맞는 응답을 돌려주는 End-point를 Web을 통해 노출한 것을 의미한다.
이러한 방법론 중 하나로 REST 라는 방식이 있다.
Rest
아키텍처 스타일 중 하나이다. Rest는 Representational State Transfer 의 줄임말이다.
자원을 이름으로 구분해 해당 자원의 상태를 주고받는 모든 것
즉,
- HTTP URI를 통해 리소스를 명시하고
- HTTP Method(POST, GET, PUT, DELETE)를 통해
- 해당 리소스(URI)에 대한 CRUD를 적용하는 것
이러한 제약을 따르는 API를 Rest API라고 한다.
GraphQL과 REST Api의 차이점
REST API는 각 리소스마다 하나의 End-point를 가지고, 이 End-point에서 해당 리소스의 모든것을 담당한다.GraphQL은 전체 API를 위해서 단 하나의 End-point를 사용한다.
엔드 포인트 차이점
- REST API
// REST API
GET /api/post/:id
POST /api/post
PUT|PATCH /api/post/:id
DELETE /api/post/:id- GraphQL
// GraphQL
// Endpoint
query | mutation: /graphql
// GET
query {
post(id: 1) {
id
post_header
}
}
// POST, DELETE, PATCH|PUT
mutation {
updatePost(id: 1, post_header: "바꿀 제목") {
id
}
}단 하나의 End-point를 가지며 각 리소스 별로 여러번의 요청을 해야하는 REST API와는 다르게, GraphQL은 여러번 요청이 필요할 경우, 원하는 정보를 하나의 Query에 모두 담아 요청하는 것이 가능하다.
장점
- OverFetching
필요로하는 정보보다 많은 데이터가 응답된 경우를 의미한다. 이는 곧 네트워크의 낭비를 의미하는데, GraphQL은 필요한 정보만 골라서 응답할 수 있기 때문에 REST API의 OverFetching을 개선했다고 볼 수 있다. - UnderFetching
필요로하는 정보보다 적은 양의 데이터가 응답된 경우를 의미한다.
만약 4개의 데이터가 필요한데, API가 너무 작은 단위로 나누어져 있어서 2개의 데이터만 응답되었다고 가정하자.
이런 경우 추가적인 데이터를 응답 받기 위해서, 추가적인 API 요청을 보내야 하는 상황이 생긴다. GraphQL은 하나의 End-point로부터 필요한 요청들을 쿼리문으로 묶어서 요청하기 때문에, 이러한 UnderFetching을 개선했다고 볼 수 있다.
등장 배경
예를 들어서 모바일 같은 경우 iOS와 안드로이드 기기간에 필요로하는 정보가 서로 상이한데, REST API에서는 이렇게 다른 부분들을 일일히 API를 구현해야 했다. 이 때문에 사용자 측에서 원하는 대로 정보를 가져올 수 있고, 편하게 정보를 수정할 수 있도록하는 표준화된 쿼리 언어인 GraphQL이 탄생했다.
마무리
가장 큰 차이점은 GraphQL을 사용하면 불필요한 데이터를 제외하고 원하는 값들로만 응답을 받을 수 있다는 장점이 있다. 이 외에도 GraphQL은 REST Api의 여러가지 한계점을 개선하였다.
그러나 이번에 내가 진행하게 될 프로젝트에서는 Http 상에서 csv 파일을 응답으로 받아오는 과정이 필요한데, 아직 GraphQL에서는 이 부분에 대한 안정화가 잘 이루어지지 않았다고 한다. 또한 실질적으로 아직은 표준이 없기 때문에, 우리가 더 잘 이해하고 있고 잘 사용할 수 있는 REST API를 프로젝트 스택으로 채택하기로 했다.
[참고]
