개발공부를 시작하기로 마음 먹은 후 몇 개의 클론코딩 중 API 구축 클론코딩에 대한 글을 적어보려 한다.
개발에 대해 무지했었던 나에게 서버 구축은 정말 신선했다.
따라하기 바빴던 강의였지만, 백엔드 개발자에 대한 꿈을 키우게 해준 강의였다.
아직도 이해되지 않는 부분이 많지만 포스팅을 하면서 정리 + 리마인드가 필요하다!
API란 무엇일까?
API란 Application Programming Interface의 약자이다.
여기서 'Interface'는 무엇과 상호작용을 하는 것으로 , 내가 TV와 상호작용을 하기 위해 ‘리모콘'을 사용하는 것이 interface이다.
요즘 리모콘에 ‘넷플릭스'로 바로 이동시켜주는 버튼이 있다. 넷플릭스 버튼은 TV를 만든 사람이 노출시킨 커맨드이다.
오래된 TV에 넷플릭스 버튼이 사용되지 못하는 이유는 오래된 TV를 만든 사람이 리모컨에 넷플릭스 기능을 노출시키지 않았기 때문이다.
리모컨처럼 버튼을 누르면 특정 명령을 실행하게 된다. 이 맥락에서 우리가 API에 대해서 생각할 땐 '누르는 버튼'을 생각해야 한다.
마찬가지로 리모컨과 같이 브라우저는 많은 버튼을 갖고 있다.
API는 우리가 사용하는 인터페이스인 것이다. 예를 들어, 프로그래밍을 할 때 어플리케이션과 상호작용을 하기 위해 사용한다. API는 어플리케이션, 서버, 웹 사이트를 만든 사람이 api를 만들어서 내놓은 것이고, 사람들은 API로 상호작용을 하는 것이다.
REST란?
API에서 가장 많이 들어본 것은 REST일 것이다.
REST API 혹은 GraphQL API는 의사소통을 위해 사용된다.
REST API와 GraphQL API의 차이점은 '버튼들이 어떻게 노출되어 있는가' 이다.
해당 API의 데이터에 어떻게 접근하는지, 서버와 어떻게 의사소통을 하는지에 대한 차이이다.
서로 다른 서버간의 통신이나 IOS 어플리케이션이 서버와 통신할 때 REST api를 사용한다면 그 통신은 URL로 이루어진다.
예를 들어, 수백만개의 영화에 대한 데이터베이스 서버를 가지고 있다 가정해보자.
나는 영화 서비스 IOS 어플리케이션을 만들고 있고 모든 영화를 정렬하고자 할 때, 서버에서 모든 데이터를 가져와야 하고 사용자들에게 그 데이터를 가공해서 보여줘야 한다.
REST api를 사용한다면 ‘nomadmovies.co/movies’ 처럼 URL로 request를 만든다.
이 URL은 JSON 배열을 제공하여 1000개~1000000개 이상의 영화들을 나열할 것이다.
데이터 뿐인 JSON을 가지고 색을 입히거나 보기 좋게 가공하여 사용자에게 보여준다. 이것이 REST api이다.
URL로 이루어져 있어 조직화되어 있고 이해하기 쉬운 편이다.
전세계의 거의 모든 디바이스들이 URL로 요청을 보낼 수 있다. URL을 요청하고 데이터를 받아오기만 하면 되는 간단한 방법으로 이루어져 있다.
REST + HTTP
우리가 웹사이트에 요청을 보낼 때 우리의 브라우저는 항상 get 요청을 보낸다.
nomadcoders.co를 입력하고 엔터를 치면 브라우저는 nomadcoders.co URL로 get 요청을 보낸다 (자동적으로)
데이터를 보내고 싶을 때에는 POST라는 HTTP 메소드를 사용한다.
(FYI, 우리는 HTTP 메소드를 만들지 못한다. HTTP 표준 명세가 존재하므로 POST를 create, add, upload 등의 단어로 바꾸지 못한다.)
하지만, ‘메소드 + URL’이 API가 더 많은 기능을 할 수 있도록 한다.
트위터의 api를 예를 들어보자.
GET /2/users/디니/bookmarks
POST /2/users/디니/bookmarks
이 URL들은 서로 같다. 어떤 메소드를 사용하는지에 따라서 백엔드 서버는 다른 일을 할 것이다. 즉, 사용자가 누르게 될 버튼이 다르다는 의미이다.
GraphQL이란?
GraphQL은 하나의 specification(명세)이다. Specification은 아이디어가 어떻게 동작하는지 설명해준다.
다른 사람들이 이 specification을 읽고 specification을 다룰 수 있는 코드를 짠다.
GraphQL은 domain-specific 언어이다. 사람들이 원하는 방식대로 구현하도록 한 언어이다.
GraphQL API의 REST API에 대한 해결책
REST API는 두 가지의 문제점이 있다.
- over-fetching
over-fetching이란 내가 쓸 데이터보다 더 많은 데이터를 받는 것이다.
이 현상은 백엔드나 데이터베이스가 필요 이상의 일을 해야한다. 또한 백엔드에서 프론트엔드로 보내줄 데이터가 많아져 데이터 전송이 느려질 수 있다.
GraphQL은 URL로 데이터를 즉시 받지 않는다. 대신 GraphQL에서는 필요한 데이터를 요청한다. 그리하여 필요한 데이터만 받을 수 있게 되므로 over-fetching을 해결할 수 있다.
2. under-fetching
under-fetching이란 내가 쓸 데이터보다 적은 데이터를 받는 것이다.
데이터를 적게 받으므로 필요한 데이터를 더 받기 위해서는 두 개(혹은 여러 개)의 URL에 request 해야한다.
한 화면을 위해 여러 개의 요청을 보낸다면 로딩시간이 길어진다. 또한 request 중 하나는 실패할 가능성이 있다.
The Star Wars API를 사용해보자.
GraphiQL은 브라우저 툴이다. graphql query를 쓰고 보낼 수 있게 해준다.
오른쪽 Root에 쓰여진 보라색&노란색 글들은 요청할 수 있는 데이터들이다. (‘요청할 수 있는 데이터' 라는 뜻은 API가 주는 데이터이다)
REST api였다면 보라색 & 노란색 글들은 URL이 될 것이다.
왼쪽에 코드를 작성하면 오른쪽에서 데이터를 받을 수 있다.
정확하게 요청한 데이터만 받은 것을 확인할 수 있다.
Star Wars film의 모든 title array를 받았다! 이것이 over-fetching의 해결책이다.
또 다른 Graphql의 장점은 모든 것들이 type을 갖고 있다. 이는 자동완성이 가능하게 만든다.
allPeople의 하나의 요청으로 name, haircolor 등의 원하는 데이터를 받았다. 이것이 under-fetching의 해결책이다.
Apollo server는 node.js 서버같은 것이지만 graphql을 이해하는 서버이다. 왜냐하면 graphql specification을 구현하고 있기 때문이다.
여기까지 API 개념에 대한 글이다.
다음 글에 직접 API를 구축하는 글을 올릴 예정이다.
'클론코딩' 카테고리의 다른 글
| Tweet API 클론코딩5 (1) | 2022.06.12 |
|---|---|
| Tweet API 클론코딩 4 (0) | 2022.06.11 |
| Tweet API 클론코딩 3 (0) | 2022.06.10 |
| Tweet API 클론코딩 2 (0) | 2022.06.09 |