SPA & REST API
핫 of 핫하다는 리액트를 이용한 토이프로젝트를 구상중이다.
본격적인 프로젝트를 시작하기 전에,
현재 웹 개발의 트렌드인 SPA 와 REST API의 개념을 정리해보려 한다.
2021년 현재, 웹 개발을 주도하는 SPA
SPA(Single Page Application)는 현재 전 세계 웹 개발의 Trend이다.
SPA는 말 그대로 페이지가 1개인 웹 어플리케이션으로, 대표적인 프레임워크로는 React, Vue.js, Angular가 있다.
왜 핫한가?
인스타그램만 써봐도 알 것이다…‘인스타 감성’으로 대표되는 유저친화적인 UX와 빠른 응답 등은 모던 어플리케이션의 감성을 그대로 담고있다.
인스타그램, 페이스북 등 핫한 어플리케이션을 쓰다가 static 사이트를 들어가면 너무 구리다는 느낌이 확 든다(내 github블로그도 static사이트라 구리다..).
그런데..우리가 보는 웹사이트는 여러 페이지로 구성이 되어있지 않은가?
어떻게 Single Page로 웹서비스를 제공하는 것이 가능한가?
이를 이해하기 위해서는 기존 Http 프로토콜에서 웹 페이지가 사용자에게 어떻게 보여지는지를 이해하는것이 중요하다.
과거 웹 서비스 서버는, 사용자에게 제공하고자하는 리소스(html 등)를 가지고 있다가
사용자 request 시 response로 적절한 자원을 제공해주는 형태였다.
즉, 서버는 클라이언트에게서 요청이 올 때만 필요한 자원을 넘겨주기만 하면 되었다.
이 특징은 Connectionless & Stateless라고 표현할 수 있는데,
요청에 따른 응답이 이루어지고 나면 서버는 더 이상 클라이언트의 상태가 어떤지 알 수 없기 때문이다.
통신의 연결, 정보의 저장을 관리할 필요가 없으므로 서버 설계가 간단하며,
많은 양의 요청에도 간단히 응답만 보내주면 되므로 처리가 용이하다.
그러나…요청을 보낼 때마다 방금 전에 보냈던 정보를 또 보내면 너무나 비효율적이므로,
쿠키 and 세션과 같은 기술로 상태와 정보를 저장할 수 있다(ex) 로그인).
또한 HTTP 1.1 부터는 Keep-alive기능을 지원하는데,
요청이 온 클라이언트와 일정 시간만큼의 연결을 가능케 하여 하나의 요청에 여러개의 응답을 처리할 수 있도록 할 수 있다.
현대의 웹/앱 어플리케이션은 사용자와의 interaction이 굉장히 다이나믹하게 이루어지도록 구성되어있다.
사용자와의 상호작용이 실시간으로 이루지는 어플리케이션에는,
아무리 Keep-alive 기술이나 쿠키, 세션과 같은 기술이 적용된 서버라도 성능이 저하될 수 있다.
따라서,
-
화면 이동 시 서버사이드에서 HTML을 전달받지 않음(서버사이드 렌더링 없음)
- 사용자와 인터렉션이 발생하면 필요한 부분만 그때그때 javascript를 통해 업데이트
- 주소에 따라 다른 View를 보여주는 것을 라우팅(Routing)이라 한다.
- 새로운 데이터 필요시 서버 api를 호출해 필요 데이터만 json으로 호출하여 사용
하는 새로운 방식의 웹 어플리케이션이 등장했는데,
이것이 바로 SPA라 할 수 있다.
Tip : 렌더링(Rendering)이란?
웹 브라우저가 서버로부터 받은 HTML, CSS를 화면에 그리는 과정이다.
각 웹 브라우저에 내장된 렌더링 엔진은 HTML, CSS를 파싱하여 트리를 형성, 레이아웃 및 노드를 화면에 나타낸다.
크롬, 사파리, 파이어폭스 등 각각의 웹 브라우저는 Blink, Webkit, Gecko 등의 엔진을 탑재하고 있다.
웹 브라우저마다 탑재하고 있는 렌더링 엔진이 다르므로,
프론트엔드 개발자들은 각 브라우저별로 프론트를 테스트하여 호환성에 문제가 있는지 검사한다.
서버사이드 렌더링(SSR)은 페이지를 이동할 때 마다 서버에 새로운 html을 요청하고, 서버가 이 요청에 연산을 통한 렌더링 결과물을 응답하는 것이고,
클라이언트사이드 렌더링(CSR)은 첫 요청시 한페이지만 불러오는 SPA방식을 뜻한다.
SPA의 장점과 단점은 다음과 같다.
장점
- html, css, javascript를 어플리케이션 생명주기에서 최초 단 한번만 로딩하고, 서버쪽에서는 렌더링에 신경쓰지 않아도 되므로 응답 속도 및 성능이 향상된다.
- 그 결과 사용자 친화적인 UX를 가지게 된다.
단점
- 클라이언트쪽이 무거워져 초기 로드 시 소요시간이 늘어난다.
- application 최초 로딩 시 사용자가 필요로 하지 않는 페이지 및 리소스를 통째로 불러오기 때문.
- SPA를 사용하게 되면 핵심로직이 클라이언트 단 javascript에 있으므로, 보안문제가 생길 수 있다.
- 검색엔진최적화(Search Engine Optimization)에 부적합하다 :
- 검색 엔진에 노출되기 위해서는 웹 크롤러, 봇들이 수집하는 컨텐츠에 포함되어야 하는데, 이 봇들은 html을 위주로 컨텐츠를 수집한다.
- 이 크롤러와 봇들은 js를 실행시키지 못한다 - body부분이 텅 비어있다.
- 따라서 CSR방식으로 구현된 SPA 페이지를 빈 페이지로 인식하게 된다(SSR의 경우엔 html이 모두 서버에 있으므로 문제 없음).
자, 그럼 SPA의 개념은 얼추 알았는데,
SPA와 REST API는 무슨 상관인가?
앞어 살펴보았듯, SPA로 구축된 웹 어플리케이션은 서버와 클라이언트의 역할 구분이 명확하다.
클라이언트가 렌더링과 사용자 인터렉션을 담당하는동안,
서버는 클라이언트가 요청하는 데이터만 그때그때 보내주면 된다.
필요한 데이터만 가볍게 보내는 서버 아키텍쳐 방식, 그것이 바로 REST API의 등장 배경이라 할 수 있겠다.
REST API
API(Application Programming Interface)란 특정 기능 및 자원을 제공하는 중간 매개체(Interface)를 의미한다.
어떤 프로그램을 사용하려고 할 때 그 프로그램의 리소스에 직접 접근하지 않고 API를 활용하므로서 원하는 결과를 얻어낼 수 있으며, 운영체제의 시스템 콜 등이 이에 해당한다.
API는 실제 리소스에 데이터를 요청하고 응답을 전송하는 역할을 하는 것이 전부다.
REST의 의미는 REpresentational State Transfer 로,
“자원의 상태(state)를 표현(Representational)하여 이루어지는 정보교환(Transfer)”이라 할 수 있다.
이게 무슨말일까..?
간단히 말하면, 어떤 약속으로 정해진 표현에 따라 자원을 주고받는 행위라 할 수 있다.
API이니 interface로서 서비스 요청과 응답을 주고받는 것일테고,
그 표현 방식이 REST라는 것을 의미한다.
자원을 주고받을 때 필요한 정보로는,
- 리소스(자원) : 요청, 응답하는 자원 (HTTP URI)
- 메서드(행위) : 자원에 대한 ‘행위’ ex) 생성, 읽기, 삭제, 수정과 같은 CRUD (HTTP Method)
- 상세 내역(표현) : 리소스에 대한 행위의 구체적 내용(HTTP Message Pay Load)이 body에 붙는다. ex) JSON, XML
이 있고, 이러한 표현 규칙에 따라 요청과 응답이 오가면 그것이 바로 REST API인 것이다.
백문이 불여일견이니, 네이버 뉴스검색 REST API 예시를 보자 (네이버 뉴스검색 API링크)
설명을 살펴보면 해당 REST API는 GET 메서드를 기본으로 사용하며,
Client ID 및 Secret 키값을 전송하면 원하는 응답을 얻을 수 있다.
요청 메서드에 따른 응답 메시지 표현은 JSON이며,
요청 URL에 display, query 등 여러 변수들이 붙어서 요청하는 것을 볼 수 있다.
이처럼 데이터에 대한 요청(CRUD)에 대해 적절한 표현으로 응답하는 것이 REST API다.
REST API의 장점으로는,
- 사용이 쉽고, 가볍다
- REST API 메시지 자체에 원하는 내용이 다 담겨있어서 해석이 쉬우며, 무거운 리소스가 아닌 xml, json 형태의 데이터가 오고가므로 가볍다.
- 서버의 역할이 명확히 분리된다
- REST API는 클라이언트에서 요청하는 데이터만 휙 보내고마는 stateless한 특성을 지닌다. 따라서 클라이언트-서버의 역할이 명확히 분리된다.
- HTTP프로토콜을 그대로 이용하므로 별도 인프라가 필요없다
- 이미 표준화된 프로토콜을 이용하므로 범용성이 보장된다.
반면, 단점은
- 표준이 딱히 존재하지 않으며,
- 한정된 메소드로 인해 설계되지 못하는 비즈니스 요구가 발생할 수 있다.
REST API로 주고받는 데이터의 형태가 RDBMSS와 잘 맞지 않으며,
따라서 NoSQL과 함께 쓰는 경우가 많다고 한다.
이 부분은 추후에 한번 더 파보도록 하자…