개요

• 왜 깃헙과 같은 기업은 api를 만드는데 REST 대신 GraphQL을 선택했을까? GraphQL은 어떤 면에서 프로그래밍의 혁신을 불러오는 것일까?
• 앞으로 FE에서는 GraphQL이 많은 자리를 차지할 것이다.

REST API & GraphQL

REST API

API란 무엇인가

• API : Application Programming Interface
• Interface : The way we interact with something (우리가 무언가와 상호작용하는 방식). 웹사이트는 사용자와 상호작용하는 인터페이스를 가지고 있다. TV는 리모콘이라는 인터페이스를 통해 시청자와 상호작용한다. 각각의 인터페이스들은 사용자에게 노출된 버튼(커맨드 수행)을 가지고 있다.
• 브라우저를 버튼을 엄청나게 많이 가진 리모콘이라고 생각하자. 아마존이든 트위터든 페이스북이든 다 API를 가지고 있다. 개발자들이 그 사이트와 상호작용을 할 수 있는 버튼을 갖고 있는 셈이다.
• 그런데 그 API는 내가 그 어플리케이션과 상호작용 하기를 바라는 사람이 만든 것이다. 인스타그램을 예로 들면, 사용자들이 사용하기를 바라는 버튼을(기능을) API를 만든 사람이 의도적으로 선택해서 노출시켜 놓았다.
• 인터페이스의 대상은 냉장고든 TV든 무엇이든 될 수 있는데, API는 어플리케이션, 서버, 웹사이트를 만든 사람이 만들어서 내 놓은 것이다. 그리고 사람들이 그를 통해 그 대상과 상호작용한다.
• 즉 API는 프로그램을 위한 인터페이스이며, 프로그램들이 서로 상호작용 하는 것을 도와주는 중간 매개체이다. 공개되어 있지 않다면 사용할 수 없다.

REST란 무엇인가

• REST API든 GraphQL API든 백엔드와 통신하기 위해 사용된다.
• REST API와 GraphQL API의 차이는 이 버튼들이 어떻게 노출되어 있는지에 있다. 어떻게 해당 API의 데이터에 접근하는지, 어떻게 서버에 접근하는지가 다르다는 것이다.
• REST API를 사용하면 통신은 URL로 이루어진다.
• 만약 우리가 수 백만 개의 영화를 데이터베이스에 가진 서버를 가지고 있다고 해 보자. 그리고 나는 iOS 어플리케이션을 만들고 있고 모든 영화를 정렬하고 싶다. 즉 서버에서 모든 데이터를 가져와야 한다는 것이고 또 사용자들에게 그것을 잘 보여주어야 함을 뜻한다.
• 내가 만약 REST API를 사용해 그 데이터들을 가져 온다면

yoneemovies.com/api/movies

이 URL은 나에게 JSON 배열을 줄 것이다. 수 백만 개의 영화에 대한 데이터를 말이다. 그리고 나는 데이터일 뿐인 이 JSON을 가지고 예쁘게 꾸며서 사용자에게 보여줄 수 있다.

• 이렇게 리소스나 리소스 목록을 얻을 때 URL의 형식을 사용하는 게 REST 방식이다.
• 그렇게 하기 위해서는 yoneemovies 웹사이트가 이 URL을 공개적으로 노출시켜야 할 것이다. 즉 웹사이트는 사람들이 이 URL을 요청하는 것을 허용해야 한다.
• 내가 그 수많은 영화 중에서 좀 더 자세히 살펴보고 싶은 영화가 있다고 해보자.

yoneemovies.com/api/movies/1

• 그리고 내가 사람들에게 영화에 대한 검색 기능을 허용하고자 한다면

yoneemovies.com/api/search?rating=9

• 내가 이 URL을 노출시키면 백엔드는 이 부분을 보고 검색 결과에 맞게 영화 목록을 필터링할 것이다.
• 이와 같은 주소들이 REST api들이 어떻게 생겼는지에 대한 모습이고 이 버튼들은 그저 URL이다.
• 이렇게 조직화되어 있으며 이해하기 쉬운 특성으로 인해 많은 사람들은 REST를 사랑한다. REST api를 이용한 작업은 정말 간단하고 전 세계의 모든 디바이스들이 URL로 요청을 보낼 수 있다. URL을 요청하고 데이터를 받아오기만 하면 되기에 아주 간단하다. 위와 같은 URL로서의 API를 요청함에 있어 그 어떤 라이브러리도 필요 없으며 안드로이드든 브라우저든 iOS든 누가 요청하는지도 관계 없이 다 가능하다.
• REST api의 컨벤션은 복수명사를 쓰는 것이다.
• REST api는 HTTP와 결합하며 더 강력해진다(그저 JSON 데이터를 보는 것 이외에, 능동적인 CRUD 작업 가능).
• 트위터의 API // 수많은 URL들로 이루어져 있다

HTTP & REST

• 새로운 영화를 만들고 싶다고 쳐보자

yoneemovies.com/api/movies/create

• 하지만 API에 동사를 넣는 것은 좋은 생각이 아니다. create를 써야 하는가? add를 쓸 수 있다. 직관적이지 않다. 그러므로 url에 동사를 넣는 것은 좋은 practice(관행)가 아니다.
• 즉 의도를 담지 않은 URL 형식이 좋은 형식이다.
• 그 대신 우리는 HTTP 메서드에 의존해야 한다.
• 우리가 웹사이트에 요청을 보낼 때 브라우저는 항상 GET 요청을 보낸다. (그저 데이터를 수동적으로 받기만 하는 것이 아니라, 어떤 어떤 조건의 데이터를 줘 -> GET 요청)
• 내가 데이터를 내가 보내고 싶을 때, 즉 form을 보내고 싶을 때는 POST 요청을 보낸다.
• 우리는 HTTP의 표준 명세를 갖고 있고 그 메소드 중에 GET과 POST가 있다. POST를 create, add, upload와 같은 단어로 바꿀 수 없다.
• 핵심은 '메서드 + URL'이 API가 더 많은 일을 할 수 있도록 해준다는 것이다.
• 트위터의 API를 살펴 보자
  
• 같은 url이지만 어떤 메서드를 사용하는지에 따라(GET이냐 POST냐) 백엔드는 다른 기능을 수행할 것이다. GET이면 브라우저가 데이터를 얻어올 것이고, POST라면 새로운 북마크를 만들게 될 것이다. PUT이라면(위 그림에는 없지만) 어떠한 수정 기능을 수행하게 될 것이다.
• REST api에서 개발자가 해야할 것은 오로지 HTTP 메서드와 URL을 조합하는 것이다. 굉장히 직관적이고 아름다운 사고방식을 담은 api라고 말할 수 있다. 아무 것도 배울 게 없다.
• recap : 데이터를 구성하고, 데이터를 주고 받고, 다른 사람에게 데이터의 수정을 허용해 주는 아주 아름다운 형식의 인터페이스. 읽고 이해하기도 쉽고 오로지 URL과 HTTP 메서드만 알면 된다.
• 그런데 GraphQL은 배울 게 좀 있다. 이렇게 아름다운 REST api를 버리고 왜 GraphQL로 건너가는 기업들이 생기는 걸까?