프런트엔드 개발자가 되기 위해서 혹은 되었다면 알아야 할 것이 정말 많은데 그중에 하나인 통신과 API에 대해서 글을 쓰려고 한다.
프런트엔드가 통신과 API를 왜 알아야 하지? 백엔드의 영역 아닌가?라는 생각이 들지도 모른다.
나도 같은 생각이었고, 큰 관심 없던 분야였으니까
하지만 생각해 보라 아주 멋지고 세련된 웹사이트(혹은 앱)을 만들고 배포도 했는데 가입 정보를 넣어도 가입이 안 된다면? 등록된 게시글을 등록하거나 수정하려고 버튼을 아무리 눌러도 반응이 없다면? 정말 아찔하지 않겠는가
물론 저런 상황일 때 100% 통신 관련 문제 일 거라곤 장담 못 하지만 그중 이유가 될 수 있다면 알아두는 게 좋지 않을까?
월드 와이드 웹(www: World Wide Web * 통칭 웹)은 인터넷에 연결된 사용자들이 서로의 정보를 공유할 수 있는 공유를 뜻한다.
인터넷과 같은 의미로 사용되고 있지만 정확히는 웹은 인터넷 서비스 중 하나이다.
우리가 자주 사용하는 네이버나 구글이 대표적인 웹이며 웹주소 제일 앞에 적혀있는 http는 두 컴퓨터 간에 텍스트/하이퍼텍스트 데이터를 주고받는 통로이다.
파일을 주고받는 경로는 FTP라고 하고, 간단한 메일류는 SMTP이라 한다.
하이퍼텍스트:
일반 텍스트와 달리 문장이나 단어 등이 링크를 통해서 서로 연결된 네트워크처럼 구성된 문서를 말한다. 대표적인 하이퍼텍스트에는 html 문서가 있다.
하이퍼텍스트가 어떤건지 잘 보여주는 BSS
무려 1991년부터 현재까지 운영하는 장수 BBS이다.
근데 위의 이미지를 보니 우리가 알던 웹사이트와는 다르지 않은가?
API란
API(Application Programming Interface 애플리케이션 프로그래밍 인터페이스, 응용 프로그램 프로그래밍 인터페이스)는 컴퓨터나 컴퓨터 프로그램 사이의 연결이다. 일종의 소프트웨어 인터페이스이며 다른 종류의 소프트웨어에 서비스를 제공한다.
출처 - 위키백과 / 22년 01월 13일 기준
컴퓨터와 사람을 연결하는 유저인터페이스(UI)와는 반대로 API는 컴퓨터와 소프트웨어를 연결시킨다.
정의만 보았을 땐 소프트웨어와 컴퓨터를 연결한다는 게 무슨 말인가 싶은데, 쉽게 말하면 Front-end에서 데이터를 Back-end에게 보냈을 때 실행되는 Back-end 기능이다.
프로그램은 생각보다 훨씬 단순해서 title: 제목입니다라고 적어도 양식에 맞춰 작성해도 작성한 데이터를 저장하는 api,작성한 데이터를 서버로 보내는 api 등 기능이 담겨있는 api가 없으면 그냥 데이터에 불과하다.
front-end에서 작성한 데이터를 Back-end의 컴퓨터로 보내고(요청) back-end는 보내준 데이터를 받았다는 답을 주어야 한다(응답) 그런 다음 받은 데이터를 데이터베이스(DB)에 저장하고 (DB는 엑셀과 같은 표로 저장된다) 그런 다음 back-end는 필요한 정보를 꺼내서 front-end가 요청한 데이터를 다시 보내준다.
단순, 데이터를 저장하는 것뿐만 아니라 DB가 수정되는 모든 작업을 할 때마다 같은 방식으로 작동하며 모든 작업엔 요청과 응답으로 이루어진다.
그런데 API의 정의와 설명을 보니 보이는 부분을 담당하는 프런트엔드 개발자보다는 데이터를 담당하는 백엔드 개발자들이 알아야 할 것 같은데 왜 프런트엔드 개발자도 알고 있어야 한다는 걸까?
그 이유는 프런트엔드 개발자는 백엔드 개발자와 함께 일을 하기 때문이다.
장난으로 하는 말이 아니라 정말이다. 각자 맡은 업무는 다르지만 함께 일을 하는 직업 특성상 원활한 커뮤니케이션과 더 나은 업무를 위해 프런트엔드 개발자들이 알고 있으면 좋을 것 같아서 복습 겸 기록을 남긴다.
그럼 api가 뭔지도 알았고 왜 알고 있어야 하는지도 알겠는데 그래서 어떻게 쓰라는 거지?
라는 생각을 하는 나와 같은 생각을 하며 이 글을 읽는 사람들을 위해서 실무에서 많이 쓴다는 rest api와 GraphQl api를 이야기하려고 한다.
1.Rest API 의 특징
REST는 Reresentational State Transfer라는 용어의 약자로 로이 필딩(Roy Fielding)의 박사학위 논문에서 최초로 소개되었는데, HTTP 주요 저자 중 한 사람으로 그 당시 웹(HTTP) 설계의 우수성에 비해 제대로 사용되지 못하는 모습에 안타까워하며 웹의 장점을 최대한 활용할 수 있는 아키텍처로써 REST를 발표했다고 한다.
REST API는 몇가지 특징을 살펴보면
검사하기
- Uniform (유니폼 인터페이스)
Uniform Interface는 URI로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍처 스타일을 말한다.
**Stateless (무상태성)**
REST는 무상태성의 성격을 가지고 있는데 작업을 위한 상태정보를 따로 저장하고 있지 않는다. 세션 정보 등 별도로 저장하고 관리하지 않기 때문에 API서버는 들어오는 요청만을 단순히 처리하면 되며, 서버의 확장성이 높은 장점이 있다. 또한 서버에서 불필요한 정보를 관리하지 않으면서 구현이 단순해지는 특징이 있다.
- Cashable (캐시 가능)
REST의 가장 큰 특징 중 하나는 http라는 기존 웹 표준을 그대로 사용하기 때문에 웹에서 사용하는 기존 인프라를 그대로 활용이 가능하다. 따라서 http가 가진 캐싱 기능이 적용 가능하며, http 프로토콜 표준에서 사용하는 last-modified 태그나 E-Tag를 이용하면 캐싱 구현이 가능해진다.
- Self-descriptveness(자체 표현 구조)**
REST의 또 다른 큰 특징 중 하나는 REST API 메시지만 보고도 이를 쉽게 이해할 수 있는 자체 표현 구조로 되어있다는 것이다.
- Client-Server 구조
REST 서버는 API 제공, 클라이언트는 사용자 인증이나 컨텍스트(세션, 로그인 정보) 등을 직접 관리하는 구조로 각각의 역할이 확실히 구분되기 때문에 클라이언트와 서버에서 개발해야 할 내용이 명확해지고 서로 간 의존성이 줄어들게 된다.
- 계층형 구조
REST 서버는 다중 계층으로 구성될 수 있으며, 보안, 로드밸런싱, 암호화 계층을 추가해 구조상의 유연성을 둘 수 있고 PROXY, 게이트웨이 같은 네트워크 기반의 중간 매체를 사용할 수 있게 한다.
2. GraphQL API의 특징
GraphQl은 페이스북에서 만든 쿼리 언어이며, gql의 문장을 클라이언트 시스템에서 작성하며 호출한다.
같은 쿼리언어인 Structed Query Language (이하 sql)과는 다르게 GraphQl은 웹클라이언트가 서버로부터 효율적으로 가져오는것을 목표로 하고있다.
예시
import { gql, useMutation, useQuery } from "@apollo/client"
import styled from "@emotion/styled"
const FETCH_BOARDS = gql`
query fetchBoards {
fetchBoards {
number
writer
title
createAt
}
}
` next.js안에서 gql을 통해 boards를 불러왔다.
[GraphQl 파이프라인 -출처 kakao Tech]
3. Rest API vs GraphQL API
참고 및 출처:2022.01기준
