
GraphQL이란? - REST API부터 알아보자
GraphQL은 REST API의 대체재 성격으로 2015년 Facebook에서 발표한 통신 API이다. GraphQL은 REST API의 단점인 Underfetching, Overfetching를 효과적으로 줄일 수 있다.
또한, GraphQL은 단일 EndPoint을 지향함으로써 /graphql에서 모든 요청을 처리한다.
Graphql의 장점을 이해하기 위해서는 REST API를 먼저 알아야 한다.
따라서, Graphql를 설명하기 전에 앞서 REST API를 간단하게 설명하겠다!
API란?
- Application Programming Interface
- 어떠한 소프트웨어가 다른 소프트웨어로부터 지정된 형식으로 요청, 명령 받을 수 있는 수단을 API라고 한다.
REST API
Roy Fielding은 2000년 박사 학위 논문에 REST (Representational State Transfer)를 정의하였다.
REST는 분산 하이퍼미디어 시스템을 위한 아키텍처 스타일이며,
간단한 의미로는 웹 상의 자료를 HTTP 위에서 별도의 전송 계층 없이 전송하기 위한 아주 간단한 인터페이스라고 생각할 수 있다.
그는 REST 아키텍처에 적용되는 6가지 제약 조건을 다음과 같이 정의했다.
- Client - Server : 일관적인 인터페이스로 분리되어야 한다.
- Stateless : 각 요청 간 클라이언트의 context가 서버에 저장되어서는 안 된다.
- Cache : 클라이언트는 응답을 캐싱할 수 있어야 한다.
- Uniform interface: 아키텍처를 단순화시키고 작은 단위로 분리(decouple)함으로써 클라이언트-서버의 각 파트가 독립적으로 개선될 수 있도록 해준다.
- Layered System : 클라이언트는 보통 대상 서버에 직접 연결되었는지, 또는 중간 서버를 통해 연결되었는지를 알 수 없다. 중간 서버는 로드 밸런싱 기능이나 공유 캐시 기능을 제공함으로써 시스템 규모 확장성을 향상시키는 데 유용하다.
- Code on demand (optional) : 자바 애플릿이나 자바스크립트의 제공을 통해 서버가 클라이언트가 실행시킬 수 있는 로직을 전송하여 기능을 확장시킬 수 있다.
거의 모든 웹사이트가 위에 적힌 6가지 제약 조건을 대체로 만족한다.
Why!?
HTTP만 잘 따라도 위 제약 조건을 대체로 만족할 수 있기 때문이다.
그렇다면 질문!
Q) 만일 제약조건 중 하나라도 지키지 못하면 REST API가 아닌가?
A) REST API를 정의한 Roy Fielding은 제약조건을 모두 지키지 못하면 REST API가 아니다라고 했다.
예로 2016년 MS에서는 REST API와 관련된 가이드를 발표하고 대부분의 개발자가 이를 납득하고 따랐지만, Roy Fielding은 이조차 REST API가 아니다 라고 했다.
Q) 그렇다면 마지막 질문으로 우리가 만드는 원격 API는 반드시 REST API여야 하는가?
A) 아니다! > “If you think you have control over the system or aren’t interested in evolvability, don’t waste your time arguing about REST.” - Roy Fielding
개발자들이 말하는 REST API란? (Roy Fielding은 아니라고 하지만..)
웹 또는 앱에서 서버로 어떠한 데이터를 요청하는 것이 REST API(HTTP를 통해 CRUD를 실행하는 API를 뜻한다.)라고 널리 쓰인다.
현재 대부분의 개발자는 엄격히 말하면 REST API가 아닌 것을 그냥 REST API가 맞다라고 한 후 쓴다.
위 링크는 DEVIEW 2017에서 발표한 REST API 관련 영상인데 한 번쯤 보는 것을 추천한다. ^^ 윗글 또한 영상을 많이 참고하였다!
REST API의 특징
각 요청이 어떤 동작이나 정보를 위한 것인지를 그 요청 자체로 추론이 가능하다.
http://binary01.me/hihi<!-- Post의 category 요청-->
http://binary01.me/melong<!-- Post 수정 요청-->
만약 위처럼 개발자가 마음으로 짠 형식으로 요청을 보내면 (내 맘대로 REST) 그 자체로는 문제가 안 될 수도 있다.
하지만! 협업할 때, 또는 인수·인계받은 개발자가 힘들어할 수도 있다!
서버에서 REST API로 요청을 보낼 때는 HTTP를 사용한다.
HTTP 또한 어떤 요청을 보낼지 형식이 정해져 있다.
(GET, POST, PUT, DELETE) 등 총 9가지가 있는데,
REST API에서는 (GET, POST, PUT, DELETE) + (PATCH) 정도만 사용한다.
예를 들어 binary01.me라는 도메인에 요청을 보내 신세계 I&C 인턴사원들의 정보를 CRUD 할 수 있다고 가정해보자.
GET : Data Read (조회할 때 사용)
$ curl -X GET http://binary01.me/interns
[
{
"id": 1,
"name": "이진수",
"job": "IT"
},
{
"id": 2,
"name": "박경남",
"job": "IT"
},
...
]
POST : Data Create (새로운 정보를 추가할 때 사용)
$ curl -X POST http://binary01.me/interns/3 -H "Content-Type: application/json" -d '{"id": 3, "name": "염유진", "job": "Infra"}'
{
"id": 3,
"name": "염유진",
"job": "Infra"
}
PUT : Data Update (기존 정보를 수정할 때 사용)
$ curl -X PUT http://binary01.me/interns/3 -H "Content-Type: application/json" -d '{"id": 3, "name": "장한나", "job": "IT"}'
{
"id": 3,
"name": "장한나",
"job": "IT"
}
PUT <-> PATCH
PUT : 정보를 통째로 바꿀 때
PATCH : 부분만 바꿀 때
POST, PUT, PATCH는 BODY가 있어서 더 많은 정보를 감춰서 보낼 수 있다.
DELETE : Data Delete (기존 정보를 삭제할 때 사용)
$ curl -X DELETE http://binary01.me/interns/1
{}
정리!
내 맘대로 만든다! -> HTTP
REST API 규칙을 지킨다! -> REST API 서비스를 사용한다!
마무리
글 제목은 GraphQL이란?? 인데 어쩌다 보니 REST API 관련 내용만 작성했다.
하지만 REST API의 대체재로 나온 GraphQL을 제대로 알기 위해선 REST API를 알아야 된다! 라고 생각해서 글을 쓰다 보니 이렇게 길어졌다..
다음 글은 REST API의 단점을 간략히 설명하고 진짜로 GraphQL에 대해서 포스팅할 예정이다 ㅎㅎ 🖐🖐🖐