이 글은 Rest API 와 GraphQL에 대해 적은 글입니다. 이 포스팅을 포함해 게시된 모든 포스팅의 큰 주제는 순차적인 흐름을 지키지 않습니다. 혼란에 주의해 주세요!
REST API(RESTful API)와 GraphQL를 알아보기 전에 API에 대해 간략히 짚고 넘어가자!!
API(Application Programming Interface)
언제나 그랬듯 알기쉽게 예시를 들어보겠다. 우리가 식당에 가면 홀에서 서빙하는 직원이 메뉴판을 가져다 준다. 그 메뉴판을 통해 음식을 정하여 점원을 통해 주문을 하게 되면, 점원은 주방 요리사에게 주문내용을 전달하게 된다. 주문을 받은 요리사는 그 즉시 요리를 시작할 것이고, 요리가 완성되면 다시 점원을 통해 요리를 전달받고 비로소 먹을 수 있게 된다. 즉, API는 프로그램과 프로그램이 서로 상호작용할 수 있도록 도와주는 매개체다.
- 나 혹은 손님 = 프로그램
- 메뉴판 = 명령 목록
- 주문 = 명령
- 요리사 = 응용 프로그램
- 요청된 메뉴전달 = 명령에 대한 값을 전달
API의 역할
1. 서버와 DB(DataBase)의 출입구
어느 누구나 DB에 접근할 수 있다면 보안문제가 심각화될 수 있다. API는 이를 방지하기 위해 허용된 사람들에게만 접근성을 부여하여, 서버와 DB에 대한 출입구 역할을 한다.
2. App과 Device가 서로 원활하게 통신가능하게 함.
말 그대로다. 이 이상의 설명은 생략한다.
3. 접속을 표준화 시킴
API는 모든 접속을 표준화 한다. 덕분에 운영체제나 기기 등과 상관없이 누구나 동일한 액세스를 얻을 수 있다.
API를 사용하는 이유?
Private API를 사용하면 개발자들이 코드 작성법을 표준화하여 간소화되고 빠른 프로세스 처리를 가능하게 한다. 게다가 소프트웨어를 통합할 때, 협업을 좀 더 용이하게 할 수 있다.
기업이 Public API와 Partner API를 사용하면 타사 데이터를 통해 브랜드 인지도를 높이는데 활용할 수 있고, 고객 DB를 확장하여 전환율까지 향상 시킬 수 있다.
🤔Private API
- 개발자가 자체 제품과 서비스를 개선하기 위해 내부적으로 발행하는 API.
🤔Public API
- 개방형 API로 누구나 접근이 가능하고 제한없이 사용할 수 있는 API.
🤔Partner API
- 기업이나 단체의 데이터 공유에 동의하여 권한을 가진자만 사용할 수 있는 API. 보통 비즈니스 관계에서 사용되며, 파트너십을 통하여 소프트웨어를 통합할 때 사용되기도 한다.
REST, REST API, RESTful
서론이 길었다. 이제 REST와 REST API에 대해 알아보자!!! 먼저 REST는 REpresentational State Transfer의 줄임말이다. REST의 정의는 다음과 같다.
REST의 정의
- 자원을 이름(자원의 표현)으로 구분하여 해당 자원의 상태(정보)를 주고 받는 모든 것을 의미
즉, 자원(Resource)의 표현(Representation)에 의한 상태 전달을 말한다. 자원은 해당 소프트웨워가 관리하는 모든 것(문서, 데이터, 소프트웨어 자체)을 말하고 상태(정보)란 데이터가 요청되는 시점에서 자원의 상태를 전달하는 것을 말한다. 여기서 데이터를 주고 받을 땐 일반적으로 JSON 또는 XML을 통해 주고 받는다.
- 월드 와이드 웹(www)과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨처 개발 아키텍처의 형식
REST는 기본적으로 웹의 기존 기술과 HTTP를 그대로 활용한다고 한다. 이 덕분에 장점을 최대한 활용할 수 있는 아키텍처 스타일이기도 하다. 또한 REST는 네트워크 상에서 클라이언트와 서버 사이의 통신 방식 중 하나다.
REST의 개념
- HTTP URI를 통해 자원을 명시하고 , HTTP Method(post,get,put,delete)를 통해 해당자원에 대한 CRUD Operation을 적용하는 것을 의미한다.
정말 이해하기 어려운 개념인데, 우선 정리하면 REST는 자원 기반의 구조 설계이며, 이 중심에 자원(Resource)가 있고 HTTP Method를 통해 자원을 처리하도록 설계되어 있다. 참고로 웹 사이트의 이미지, 텍스트, DB내용 등의 모든 자원에는 고유한 ID인 HTTP URI를 부여한다.
🤔CRUD Operation
- 컴퓨터 소프트웨어가 가지는 기본적인 데이터 처리 기능들을 말한다.
- Create: 생성(POST)
- Read: 조회(GET)
- Update: 수정(PUT)
- Delete: 삭제(DELETE)
- HEAD: header 정보 조회(HEAD)
REST의 특징과 장단점
- REST는 자원, 행위, 표현 3가지 구성 요소로 이뤄져 있다.
자원(Resource): URI
- 모든 자원엔 고유한 ID가 있으며 서버에 존재하며, 구별하는 ID는 HTTP URI다.
- 클라이언트는 URI를 통해 자원을 지정하고 자원의 상태를 조작하기 위해 서버에 요청한다.
행위(Verb): HTTP Method
- HTTP Method를 사용하며 GET, POST, PUT, DELETE와 같은 메서드를 제공한다.
표현(Representation)
- 클라이언트가 요청한 것을 서버에서 응답하게 된다.
- JSON, XML 등 여러 형태의 표현으로 나타내어 진다.(이외에도 TEXT, RSS 등이 있다.)
- REST의 장점
- HTTP 프로토콜의 인프라를 그대로 사용한다. 덕분에 REST API를 사용하기 위해 별도의 인프라 구축이 필요없다.
- HTTP 표준 프로토콜을 따르는 모든 플랫폼에서 호환되므로 범용성에서 뛰어나다.
- REST API 메시지가 의도하는 바를 명확하게 나타내므로 의도하는 바를 쉽게 파악할 수 있다.
- 서버와 클라이언트의 역할이 명확하다.
- REST의 단점
- 표준이 없다.
- 사용가능한 Method가 4가지 뿐이다.
- 브라우저 버전에 따라 호환이 제각각이다.
ex) PUT, DELETE Method 사용 불가, pushState 미지원 등
🤔REST는 왜 필요할까??
- App의 분리 및 통합
- 다양한 클라이언트의 등장
- Android, iOS등 다양한 디바이스와 멀티 플랫폼에 대한 지원과 통신 방법이 필요해짐.
>>> REST를 통해 서비스 자원에 대한 아키텍처를 구축하고 이용할 방법을 생각할 수 있게 됨.
REST API의 정의와 특징
- REST를 기반으로 한 서비스 API
- REST API는 REST 기반으로 시스템을 분산하여 확장성과 재사용성을 높여 유지보수와 운용을 편리하게 한다.
- HTTP 표준을 기반으로 하므로, HTTP를 지원하는 프로그램 언어라면 클라이언트와 서버를 구현할 수 있다.
- REST를 기반으로 API를 설계할 때 따르는 규칙들이 존재하며, 이 설계규칙덕분에 자료의 재사용과 유지보수가 용이하다.
(설계 규칙에 대해선 이 포스팅에서 다루지 않는다.)
RESTful의 개념
- REST라는 아키텍처를 구현하는 웹 서비스를 나타내기위해 사용되는 용어
이 문장도 적어놓고 참 이해하기 어렵고, 애매한 문장이라고 생각한다. 하지만, 다음에 언급하는 RESTful의 근본적인 목적을 보면 이해가 쉬울것이고, 개인적으로 이 근본적인 목적이 가장 중요한 개념이라고 생각한다.
- RESTful의 목적은 이해하기 쉽고 쉬운 API를 만드는 것이다.
RESTful의 근본적인 목적은 성능 향상이 아니다. 일관적인 컨벤션을 통해 호환성을 높이는 것이 가장 큰 목적이다.
🤔RESTful 하지 못한 경우??
- CRUD 기능을 모두 POST로만 처리할 때
GraphQL
GraphQL의 정의와 필요한 이유
GraphQL은 Graph Query Language의 줄임말이다. 여기서 Query Language란, 정보를 얻기 위해 보내는 질문(Query)을 만들기 위해 사용되는 컴퓨터 언어의 일종을 말한다. GraphQL은 이런 Query Language중에서도 서버 API를 통해 정보를 주고받기 위해 사용하는 Query Language다. 그렇다면 GraphQL이 왜 탄생했고 RESTful API와 차이점은 무엇일까?
- RESTful API의 한계
- RESTful API를 이용하게 되면 원하는 정보를 가져올 수 없다. 예시를 통해 설명을 보충해보겠다.
어느 날 갑자기 햄버거가 먹고 싶어졌다. 그런데 정말 '햄버거'만 먹고 싶은데 주문 가능한 메뉴가 세트메뉴가 없다면 우리는 결국 단품을 먹기위해 세트메뉴를 주문하게 될 것이다.(물론 주문을 안하는 방법도 있지만, 설명을 돕기 위해 무조건 주문하도록 하자.) RESTful API 방법이 딱 이렇다. 하나의 정보를 가져오기 위해 모든 정보를 불러오기 때문에 불필요한 작업이나 메모리를 차지하는 경우가 발생한다. 소수의 요청이라면 큰 문제가 되지 않겠지만, 이것이 점점 누적된다면 처리속도나 용량 등 효율면에서 좋지 못하다. 그래서 등장한 것이 바로 GraphQL이다.
GraphQL의 장점
- HTTP의 요청을 줄일 수 있다.
앞서 언급했지만, RESTful API는 하나의 정보를 위해 모든 정보를 불러들인다. 따라서 요청 횟수가 필요한 응답(Response)의 종류과 비례한다. 반면 GraphQL을 사용하면 원하는 정보를 하나의 Query에 담아 요청할 수 있다.
- HTTP의 Size를 줄일 수 있다.
위의 내용과 연결되는 부분인데, 필요한 정보만 요청하는 것이 힘든 RESTful API에 비해, 원하는 대로 정보를 가져올 수 있는 GraphQL은 메모리와 용량면에서 큰 효율을 보인다.
GraphQL의 단점
- 파일 전송, Text 만으로 하기 힘든 내용들을 처리하기 복잡하다.
- 고정된 요청과 응답이 필요할 때, 메모리와 용량면에서 비효율적이다.
- 재귀적인 Query가 불가능하다.
즉, 결과에 따라 응답의 깊이가 깊어지는 API를 구축할 수는 없다.
🤔RESTful API와 GraphQL은 언제 적용시켜야 적합할까?
- RESTful API
- 파일 전송, 단순한 Text로 처리하기 힘든 요청이 있을 때
- 요청의 구조가 정해져 있을 때
ex) 컨벤션
- GraphQL
- 대부분 요청이 CRUD를 따를 때
- 서로 다른 형태와 다양한 요청에 응답해야 할 때
'ivory's DevLog' 카테고리의 다른 글
| SSR(Sever Side Rendering)과 CSR(Client Side Rendering) (1) | 2020.09.30 |
|---|---|
| Cookie? Local, Session Storage?? (0) | 2020.09.25 |
| 브라우저 렌더링 과정 (0) | 2020.09.23 |
| [JavaScript] - Callback과 Promise (0) | 2020.09.18 |
| [JavaScript] - 동기와 비동기 (0) | 2020.09.16 |