기술 면접(REST)

유요한·2024년 2월 23일

기술면접

목록 보기

9/27

REST 란 무엇입니까?

REST는 2000년도에 로이 필딩 (Roy Fielding)의 박사학위 논문에서 최초로 소개되었습니다. 로이 필딩은 HTTP의 주요 저자 중 한 사람으로 그 당시 웹(HTTP) 설계의 우수성에 비해 제대로 사용되어지지 못하는 모습에 안타까워하며 웹의 장점을 최대한 활용할 수 있는 아키텍처로써 REST를 발표했다고 합니다.

먼저 REST란 Representational State Transfer의 약자로 월드 와이드앱(WWW)과 같은 분산 하이퍼미디어 시스템 아키텍처의 한 형식입니다. 주고받는 자원(Resource)에 이름을 규정하고 URI에 명시해 HTTP 메서드(GET, POST, PUT, DELETE)를 통해 해당 자원의 상태를 주고 받는 것을 의미합니다. REST는 서버와 클라이언트의 통신 방식 중 하나이고 HTTP URI(Uniform Resource Identifier)를 통해 자원을 명시하고 HTTP MEthod를 통해 자원을 교환하는 것입니다.

REST 개념

어떤 자원에 대해 CRUD(Create, Read, Update, Delete) 연산을 수행하기 위해 URI(Resource)로 GET, POST 등의 방식(Method)을 사용하여 요청을 보내며, 요청을 위한 자원은 특정한 형태(Representation of Resource)로 표현됩니다.

URI 와 URL의 차이점?

URL은 Uniform Resource Locator로 인터넷 상 자원의 위치를 의미합니다. 반면 URI는 Uniform Resource Identifier로 인터넷 상의 자원을 식별하기 위한 문자열의 구성으로, URI는 URL을 포함하게 됩니다. URI가 URL보다 포괄적인 범위라고 할 수 있습니다.

API란?

Application Programming Interface의 약자로, 특정 프로그램을 만들기 위해 제공되는 모듈(함수 등)을 의미한다. API란 정의 및 프로토콜 집합을 사용하여 두 소프트웨어 구성 요소가 서로 통신 할 수 있게하는 메커니즘 입니다. 예를들어, 기상청의 소프트웨어 시스템에는 일일 기상 데이터가 들어 있습니다. 휴대폰의 날씨 앱은 API를 통해 이 시스템과 "대화"하고 휴대폰에 매일 최신 날씨 정보를 표시합니다. API는 Application Programming Interface(애플리케이션 프로그램 인터페이스)의 줄임말입니다. API의 맥락에서 애플리케이션이라는 단어는 고유한 기능을 가진 모든 소프트웨어를 나타냅니다. 인터페이스는 두 애플리케이션 간의 서비스 계약이라고 할 수 있습니다. 이 계약은 요청과 응답을 사용하여 두 애플리케이션이 서로 통신하는 방법을 정의합니다.

💡REST API란 무엇입니까?

REST(Representational State Transfer)란 네트워크 아키텍처 스타일이다. 여기서 네트워크 아키텍처 스타일란 네트워크 자원을 정의하고 처리하는 방법 전반을 일컫는다. REST API는 대중적으로 많이 사용되는 애플리케이션 인터페이스입니다. REST 아키텍처의 조건을 준수하는 어플리케이션 프로그래밍 인터페이스를 뜻합니다. 최근 많은 API가 REST API로 제공되고 있고 일반적으로 REST 아키텍처를 구현하는 웹 서비스를 RESTful하다고 표현합니다. 이 인터페이스를 통해 클라이언트는 서버에 접근하고 자원 조작할 수 있습니다.

RESTful API는 두 컴퓨터 시스템 간의 안전한 온라인 정보 교환을 가능하게 합니다. 다양한 활동을 완료하기 위해 대부분의 비즈니스 애플리케이션 은 다른 내부 및 외부 프로그램과 데이터를 교환합니다. 예를 들어, 내부 계정 시스템이 급여 명세서를 생성하기 위해 외부 은행 시스템과 직원 정보를 공유하는 경우. 이 정보는 개별 개인이며 REST API 소프트웨어 표준은 안전하고 효율적이며 신뢰할 수 있으므로 REST API로 수행할 수 있습니다.

RESTful API는 어떤 식으로든 REST에 연결되는 API로 알려져 있습니다. 모든 데이터는 REST API에서 리소스로 간주되며 정확한 표준 상수 단위(URI)에 의해 결정됩니다. Twitter API는 사용자가 액세스하고 검색할 수 있는 리소스로 트윗을 생성합니다. Twitter API를 사용하여 사용자는 쉽게 트윗을 게시할 수 있습니다.

Representational State Transfer API의 약자로, HTTP프로토콜을 통해 서버 제공 기능을 사용할 수 있는 함수를 의미 일반적으로 XML, JSON의 형태로 응답을 전달(원하는 데이터 추출이 수월)
REST는 클라이언트가 서버 데이터에 엑세스 하는 데 사용할 수 있는 GET, PUT, DELETE 등의 함수 집합을 정의합니다. 클라이언트와 서버는 HTTP를 사용하여 데이터를 정의합니다.
REST API의 주된 특징은 무상태입니다. 무상태는 서버가 요청간에 클라이언트 데이터를 저장하지 않음을 의미합니다. 서버에 대한 클라이언트 요청은 웹 사이트를 방문하기 위해 브라우저에 입력하는 URL과 유사합니다. 서버의 응답은 웹 페이지의 일반적인 그래픽 렌더링 없는 일반 데이터입니다.

💡REST의 원칙은 무엇입니까?

REST 아키텍처 스타일은 6가지 제약 조건으로 구성한다. 이 가이드라인을 따르는 API를 RESTful API라고 합니다. 즉, REST 아키텍처를 구현하는 웹 서비스를 RESTful하다라고 표현합니다.

REST 제약조건

클라이언트-서버(Client-Server)

무상태성(Stateless)

캐시가능한 데이터(Cacheable)

유니폼 인터페이스(Uniform Interface)

계층화(Layered System)

코드 온-디맨드(Code-On-Demand)

클라이언트 서버
클라이언트-서버라는 것은 리소스를 관리하는 서버가 존재하고 다수의 클라이언트가 리소스를 소비하기 위해 네트워크를 통해 서버에 접근하는 구조를 의미한다. 이런 구조 중 우리에게 가장 친숙한 것이 바로 웹 애플리케이션이다.

자원이 있는 족이 Server, 요청하는 쪽이 Client
클라이언트와 서버가 독립적으로 분리되어 있어야 한다.

리소스란?
리소스란 REST API가 리턴할 수 있는 모든 것을 의미합니다.
예를들어 HTML, JSON, 이미지 등이 있습니다.

무상태성

요청 간에 클라이언트 정보가 서버에 저장되지 않음
서버는 각각의 요청을 완전히 별개의 것으로 인식하고 처리

무상태성이라는것은 서버에 상태 정보를 따로 보관하거나 관리하지 않는다는 의미입니다. 서버는 클라이언트가 보낸 요청에 대해 세션이나 쿠키 정보를 별도 보관하지 않습니다. 그렇기 때문에 한 클라이언트가 여러 요청을 보내든 여러 클라이언트가 각각 하나의 요청을 보내든 개별적으로 처리합니다. 이렇게 구성된 서비스는 서버가 불필요한 정보를 관리하지 않으므로 비즈니스 로직의 자유도가 높고 설계가 단순합니다.

클라이언트가 서버에 요청을 보낼 때, 이전 요청의 영향을 받지 않음을 의미합니다. 예를 들어 /login으로 로그인 요청을 보내고, 로그인이 되어 다음 페이지인 /page로 넘어갔다고 하면 /page로 리소스를 불러올 때, 이전 요청에서 login한 사실을 서버가 알고 있어야 한다면 그것은 상태가 있는 아키텍처이다. 서버가 그 사실을 알지 못한다면 상태가 없는 것이다.

그러면 로그인은 어떻게 해야 할까? 또는 부득이한 경우 상태를 어떻게 유지하는가? 클라이언트는 서버에 요청을 날릴 때마다 요청에 리소스를 받기 위한 모든 정보를 포함해야 합니다. 예를들어, 로그인의 경우 서버는 로그인 상태를 유지하지 못하므로 요청을 보낼 때마다 로그인 정보를 항상 함께 보내야 합니다. 리소스를 수정 후 수정한 상태를 유지해야 하는 경우는 서버가 아닌 데이터베이스 같은 퍼시스턴스에 상태를 저장해야 합니다.

HTTP는 기본적으로 상태가 없는 프로토콜이다. 따라서 HTTP를 사용하는 웹 애플리케이션은 기본적으로 상태가 없는 구조를 따른다.

캐시 가능
서버에서 리소스를 리턴할 때 캐시가 가능한지 아닌지 명시할 수 있어야 합니다. HTTP에서는 cache-control이라는 헤더에 리소스의 캐시 여부를 명시할 수 있습니다.

REST는 HTTP 표준을 그대로 사용하므로 HTTP의 캐싱 기능을 적용할 수 있습니다. 이 기능을 이용하기 위해서는 응답과 요청이 모두 캐싱 가능한지(Cacheable) 명시가 필요하며, 캐싱이 가능한 경우 클라이언트에서 캐시에 저장해두고 같은 요청에 대해서는 해당 데이터를 가져다 사용합니다. 이 기능을 사용하면 서버의 트랜잭션 부하를 줄어 효율적이며 사용자 입장에서 성능이 개선됩니다.

유니폼 인터페이스(균일한 인터페이스)
유니폼 인터페이스란 일관적인 인터페이스를 의미합니다. 일관적인 인터페이스라는 것은 시스템 또는 애플리케이션의 리소스에 접근하기 위한 인터페이스가 일관적이어야 한다는 뜻이다. 즉, REST 서버는 HTTP 표준 전송 규약을 따르기 때문에 어떤 프로그래밍 언어로 만들어졌느냐와 상관없이 플랫폼 및 기술에 종속되지 않고 타 언어, 플랫폼, 기술 등과 호환해 사용할 수 있다는 것을 의미합니다.

계층화 시스템
클라이언트와 API 서버 사이에서 계층은 서버입니다. 이러한 서로 다른 서버는 스팸 탐지 및 성능 향상과 같은 여러 작업을 수행합니다. REST(표현 상태)는 모듈식 아키텍처를 사용하기 때문에 클라이언트와 API(응용 프로그래밍 인터페이스) 서버 간에 전송되는 메시지는 계층을 추가하거나 제거해도 영향을 받지 않습니다.

클라이언트 애플리케이션은 자체 백엔드에서 코드를 실행할 수 있습니다.

REST API 구성

REST API는 다음과 같이 구성된다.

자원(RESOURCE) - URI
모든 자원에 고유한 ID가 존재하고, 이 자원은 Server에 존재한다. 자원을 구별하는 ID는 ‘/groups/:group_id’와 같은 HTTP URI이다. Client는 URL를 이용해서 자원을 지정하고 해당 자원의 상태(정보)에 대한 조작을 Server에 요청한다.
행위(Verb) - HTTP METHOD
HTTP 프로토콜의 Method(GET, POST, PUT, DELETE)를 사용한다.

표현(Representations)
Client가 자원의 상태(정보)에 대한 조작을 요청하면 Server는 이에 적절한 응답(Representation)을 보낸다. REST에서 하나의 자원은 JSON, XML, TEXT, RSS 등 여러 형태의 Representation으로 나타내어 질 수 있다. 보통 JSON 혹은 XML를 통해 데이터를 주고 받는 것이 일반적이다.

💡REST API를 사용하면 장점

1. 통합
API는 새로운 애플리케이션을 기존 소프트웨어 시스템과 통합하는데 사용됩니다. 그러면 각 기능을 처음부터 작성할 필요가 없기 때문에 개발 속도가 빨라집니다. API를 사용하여 기존 코드를 활용할 수 있습니다.

2. 혁신
새로운 앱의 등장으로 전체 산업이 바뀔 수 있습니다. 기업은 신속하게 대응하고 혁신적인 서비스의 신속한 배포를 지원해야 합니다. REST API를 사용하면 코드를 다시 작성할 필요 없이 API 수준에서 변경하여 이를 수행합니다.

3. 확장
API는 기업이 다양한 플랫폼에서 고객의 요구 사항을 충족할 수 있는 고유한 기회를 제공합니다. 예를 들어 지도 API를 사용하면 웹 사이트, Android, iOS 등을 통해 지도 정보를 통합할 수 있습니다. HTTP 표준 프로토콜을 사용하는 모든 플랫폼에서 호환 가능

최근의 서버 프로그램은 다양한 브라우저와 안드로이드폰, 아이폰과 같은 모바일 디바이스에서도 통신을 할 수 있어야한다.

4. 유지 관리의 용이성
API는 두 시스템 간의 게이트웨이 역할을 합니다. API가 영향을 받지 않도록 각 시스템은 내부적으로 변경해야 합니다. 이렇게 하면 한 시스템의 향후 코드 변경이 다른 시스템에 영향을 미치지 않습니다. 서버와 클라이언트의 역할을 명확하게 분리

💡REST API를 보호하려면

1. 인증 토큰
인증 토큰은 사용자에게 API를 호출을 수행할 수 있는 권한을 부여하는데 사용된다. 인증 토큰은 사용자가 자신이 누구인지 확인하고 해당 특정 API호출에 대한 엑세스 권한이 있는지 확인한다.

2. API 키
API 키는 API를 호출하는 프로그램 또는 애플리케이션을 확인합니다. 즉, 애플리케이션을 식별하고 애플리케이션에 특정 API 호출을 수행하는 데 필요한 엑세스 권한이 있는지 확인합니다. API 키는 토큰만큼 안전하지 않지만 사용량에 대한 데이터를 수집하기 위해 API 모니터링을 허용합니다. 다른 웹 사이트를 방문할 때 브라우저 URL에서 긴 문자열과 숫자가 웹 사이트가 내부 API 호출을 수행하는데 사용하는 API키입니다.

REST API 설계 예시

💡REST에서 지원하는 HTTP 메서드는 무엇입니까?

REST HTTP 지원 방법은 다음과 같습니다.

GET : 웹사이트 및 API에서 가장 광범위하게 사용되는 방법인 GET은 특정 데이터 서버에서 리소스를 수신합니다.
POST : POST 메서드를 통해 리소스를 업데이트하기 위해 데이터가 API 서버로 전송됩니다. 서버가 데이터를 수신하면 HTTP 요청 본문에 저장합니다.
PUT : 리소스를 생성하고 업데이트하기 위해 API에 데이터를 보냅니다.
DELETE : 이름에서 알 수 있듯이 이 메서드는 특정 URL의 리소스를 삭제하는 데 사용됩니다.
옵션 : 지원되는 기술에 대해 자세히 설명합니다.

Get 방식

클라이언트에서 서버로 데이터를 전달할 때, 주소 뒤에 "이름"과 "값"이 결합된 스트링 형태로 전달
주소창에 쿼리 스트링이 그대로 보여지기 때문에 보안성이 떨어진다.
길이에 제한이 있다.(=전송 데이터의 한계가 있다.)
Post방식보다 상대적으로 전송 속도가 빠르다.

Post 방식

일정 크기 이상의 데이터를 보내야 할 때 사용한다.
서버로 보내기 전에 인코딩하고, 전송 후 서버에서는 다시 디코딩 작업을 한다.
주소창에 전송하는 데이터의 정보가 노출되지 않아 Get방식에 비해 보안성이 높다.
속도가 Get방식보다 느리다.
쿼리스트링(문자열) 데이터 뿐만 아니라, 라디오 버튼, 텍스트 박스 같은 객체들의 값도 전송가능.

Get과 Post 차이점

Get은 주로 웹 브라우저가 웹 서버에 데이터를 요청할 때 사용
Post는 웹 브라우저가 웹 서버에 데이터를 전달하기 위해 사용.
Get을 사용하면 웹 브라우저에서 웹 서버로 전달되는 데이터가 인코딩되어 URL에 붙는다.
Post방식은 전달되는 데이터가 보이지 않는다.
Get방식은 전달되는 데이터가 255개의 문자를 초과하면 문제가 발생할 수 있다.
웹서버에 많은 데이터를 전달하기 위해서는 Post 방식을 사용하는 것이 바람직하다.

💡PUT과 POST의 차이점은 무엇입니까?

PUT과 Post의 차이점은 다음과 같습니다.

PUT : 제공된(균일한 리소스 식별자) URI에서 파일 또는 리소스를 정확하고 구체적으로 식별합니다. PUT은 기존 파일이 URI(Uniform Resource Identifier)에 있는 경우 기존 파일을 변경합니다. PUT는 파일이 이미 존재하는 경우 파일을 형성합니다. 또한 PUT은 멱등성이기 때문에 파일이 사용되는 빈도에는 영향을 미치지 않습니다.
POST : 데이터를 고유한 균일 리소스 식별자(URI)로 보내고 거기에 있는 리소스 파일이 수요를 관리할 것으로 예상합니다. 이 순간 웹사이트 서버는 선택한 파일의 컨텍스트에서 데이터로 수행할 수 있는 작업을 결정할 수 있습니다. 또한 POST 전략은 멱등성이 아니므로 두 번 이상 사용하면 새 파일 생성이 재개됩니다.

URI란?

URI(Uniform Resource Identifier)를 URI라고 합니다. REST의 URI는 웹 서버의 리소스를 지정하는 문자열입니다. 각 리소스에는 HTTP 요청에서 사용될 때 클라이언트가 이를 대상으로 지정하고 작업을 수행할 수 있도록 하는 고유한 URI가 있습니다. 주소 지정은 URI를 사용하여 리소스로 트래픽을 보내는 프로세스입니다.

URI 형식은 다음과 같습니다.

<프로토콜>://<서비스 이름>/<리소스 유형>/<리소스 ID>

URI에는 두 가지 유형이 있습니다.
1. URL - 해당 위치에서 리소스 검색에 대한 정보는 Uniform Resource Locator에서 사용할 수 있습니다.

URL에는 네트워크 호스트 이름(sampleServer.com) 및 콘텐츠 경로(/samplePage.html)에 대한 정보가 포함되어 있으며 프로토콜(예: FTP, HTTP 등)로 시작합니다. 검색 기준이 있을 수도 있습니다.

URN - 고유하고 내구성 있는 이름을 사용하여 균일한 자원 이름이 자원을 식별합니다.

인터넷에서 리소스의 위치는 URN에 의해 반드시 지정되지는 않습니다. 리소스를 식별할 때 다른 파서가 사용할 모델 역할을 합니다.

RESTful

REST API를 제공하는 웹 서비스

RESTful은 일반적으로 REST라는 아키텍처를 구현하는 웹 서비스를 나타내기 위해 사용되는 용어이다

‘REST API’를 제공하는 웹 서비스를 ‘RESTful’하다고 할 수 있다.
RESTful은 REST를 REST답게 쓰기 위한 방법으로, 누군가가 공식적으로 발표한 것이 아니다.

즉, REST 원리를 따르는 시스템은 RESTful이란 용어로 지칭된다.

Resource

URI(Uniform Resource Identifier), 인터넷 자원을 나타내는 유일한 주소

XML, HTML, JSON

RESTful 구조

RESTful의 목적

이해하기 쉽고 사용하기 쉬운 REST API를 만드는 것
RESTful한 API를 구현하는 근본적인 목적이 성능 향상에 있는 것이 아니라 일관적인 컨벤션을 통한 API의 이해도 및 호환성을 높이는 것이 주 동기이니, 성능이 중요한 상황에서는 굳이 RESTful한 API를 구현할 필요는 없다.

💡RESTful 웹 서비스의 단점을 알려주실 수 있나요?

RESTful 웹 서비스의 단점은 다음과 같습니다.

어시스턴트가 무국적자의 개념을 고수하기 때문에 RESTful 웹 서비스의 세션을 유지 관리할 수 없습니다.
보안 및 보호 제한은 REST에 필수적인 것은 아닙니다. 일부 프로토콜은 안전 보호를 위해 사용됩니다. 이렇게 하면 SSL/TLS 인증과 같이 선택할 보호 및 안전 표준을 결정할 때 사용할 수 있는 경고가 표시됩니다.

💡Restful API에 대해 설명해주세요.

Restful API는 HTTP 통신을 Rest 설계 규칙을 잘 지켜서 개발한 API를 Restful한 API라고 합니다. Rest 설계 규칙은 URI는 정보의 자원만 표현해야 하며, 자원의 상태와 행위는 HTTP Method에 명시하는걸 말합니다.

💡RESTful 웹 서비스의 기능은 무엇입니까?

다음 기능은 모든 RESTful 웹 서비스에 있습니다.

클라이언트-서버 통신 모델은 서비스의 기초입니다.
이 서비스는 HTTP 프로토콜을 사용하여 데이터/리소스를 가져오고 쿼리를 실행하고 기타 작업을 수행합니다.
"메시징"은 클라이언트와 서버 간의 통신에 사용되는 방법입니다.
서비스는 URI를 사용하여 리소스에 액세스할 수 있습니다.
이는 클라이언트의 요청과 응답이 다른 사람에게 의존하지 않는다는 무국적 개념을 준수하므로 필요한 데이터를 얻을 수 있다는 완전한 확신을 제공합니다.
동일한 유형의 반복 요청에 대한 서버 호출을 줄이기 위해 이러한 서비스는 캐싱 개념도 사용합니다.
이러한 서비스는 SOAP 서비스를 사용하여 REST 아키텍처 패턴을 구현할 수도 있습니다.

💡REST API와 RESTful API 차이점

RESTful은 REST의 설계규칙을 잘 지켜서 설계한 좀더 REST 같은것을 RESTful이라고 한다. 차이가 없어보일순 있으나 REST의 원리를 잘 따르는 시스템을 RESTful이라고 칭한다.

@RestController

package com.example.shopping;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
@SpringBootApplication
public class ShoppingApplication {

    public static void main(String[] args) {
        SpringApplication.run(ShoppingApplication.class, args);
    }

    @GetMapping(value = "/")
    public String HelloWorld() {
        return "Hello World";
    }
}

@RestController는 Restful Web API를 좀 더 쉽게 만들기 위해 스프링 프레임워크 4.0에 도입된 기능입니다. @Controller와 @ResponseBody를 합쳐놓은 어노테이션입니다. @ResponseBody 어노테이션은 자바 객체를 HTTP 응답 본문의 객체로 변환해 클라이언트에게 전송합니다. 이를 통해 따로 html 파일을 만들지 않아도 웹 브라우저에 "Hello World"라는 문자열을 출력할 수 있습니다.

  @GetMapping("/ex15")
    public @ResponseBody SampleDTO ex15() {
        log.info("/ex15............");

        SampleDTO dto = new SampleDTO();
        dto.setAge(10);
        dto.setName("홍길동");

        return dto;
    }

스프링 MVC는 자동으로 브라우저에 JSON 타입으로 객체를 변환해서 전달하게 됩니다.

스프링 MVC는 리턴 타입에 맞게 데이터를 변환해 주는 역할을 지정할 수 있는데 기본적으로 JSON은 처리가 되므로 별도의 설정이 필요하지 않습니다.

클라이언트에서 서버로 통신하는 메시지를 요청(request) 메시지라고 하며, 서버에서 클라이언트로 통신하는 메시지를 응답(response) 메시지라고 합니다. 비동기통신을 하기위해서는 클라이언트에서 서버로 요청 메세지를 보낼 때, 본문에 데이터를 담아서 보내야 하고, 서버에서 클라이언트로 응답을 보낼때에도 본문에 데이터를 담아서 보내야 합니다.

이 본문이 바로 body 이다.
즉, 요청본문 requestBody, 응답본문 responseBody 을 담아서 보내야 한다.

GraphQL이란?

GraphQL은 Facebook에서 처음으로 개발했고, 오픈 소스로 제공된 쿼리 언어이다. 쿼리(Query)란 데이터베이스나 파일의 내용 중 원하는 내용을 검색하기 위하여 몇 개의 코드(code)나 키(Key)를 기초로 질의하는 것을 말한다.

특징

GraphQL은 HTTP를 통해 API 서버로 요청을 보내고 응답을 받는다.
응답을 받을 시, 데이터 결과를 JSON 형식으로 받는다.
GraphQL은 서버 개발자가 작성한 각 필드에 대응하는 resolver 함수로 각 필드의 데이터를 조회할 수 있다.
GraphQL은 GraphQL 라이브러리가 조회 대상 schema가 유효한지 검사한다.

resolver (리졸버)

요청에 대한 응답을 결정해주는 함수로써 GraphQL의 여러 가지 타입 중 Query, Mutation, Subscription과 같은 타입의 실제 일하는 방식 즉 로직을 작성한다. 스키마 필드에 사용되는 함수의 실제 행동을 Resolver에서 정의한다.

schema (스키마)

데이터베이스에서 자료의 구조, 자료의 표현 방법, 자료 간의 관계를 형식 언어로 정의한 구조이다. 데이터베이스 관리 시스템(DBMS)이 주어진 설정에 따라 데이터베이스 스키마를 생성하며, 데이터베이스 사용자가 자료를 저장, 조회, 삭제, 변경할 때 DBMS는 자신이 생성한 데이터베이스 스키마를 참조하여 명령을 수행한다.

단점

캐싱이 REST보다 훨씬 복잡하다. GraphQL에선 POST 메소드만을 이용해 요청을 보내는데, 각 메소드가 가지는 캐싱을 지원 받을 수 없다.
고정된 요청과 응답만 필요할 경우에는 Query 로 인해 요청의 크기가 RESTful API 의 경우보다 더 크다.

장점

유연한 쿼리
GraphQL은 쿼리의 구조와 복잡성 측면에서 REST API보다 더 유연하다고 볼 수 있습니다. GraphQL을 사용하면 클라이언트 사이드에서 여러 리소스와 관계를 포함하는 복잡한 쿼리를 만들 수도 있으며, 쿼리 중첩을 통해 계층적 방식으로 데이터를 검색할 수도 있습니다.

필요한 정보들만 선택하여 받아올 수 있음(효율성 향상)
- Overfetching 문제 해결
  
  불 필요한 데이터도 한꺼번에 가져오는 문제
- 데이터 전송량 감소
여러 계층의 정보들을 한 번에 받아올 수 있음
- Underfetching 문제 해결
  
  한 번의 요청으로 필요한 데이터를 모두 받아오지 못해 여러 번의 요청을 수행하는 것을 의미
- 요청 횟수 감소
하나의 endpoint에서 모든 요청을 처리

하나의 URI에서 POST로 모든 요청 가능
graphql 서버를 실행하면 POSTMAN과 유사한 playground라는 GUI를 이용해 resolver와 schema를 한 눈에 보고 테스트 해 볼 수 있다.

사용법

REST API 의 GET 요청 -> GraphQL에서는 query를 이용해 원하는 데이터를 요청한다.

query : 저장된 데이터를 가져오기

query {
  teams {
  	manager
  	office
 }
}

이렇게 하면 team에 대한 데이터를 가져오지만 manager, office만 가져온다.

query {
  teams(id: 2) {
  	manager
  	office
 }
}

이렇게 하면 id가 2번인 team에 대한 정보만 가져온다.

Create, Delete와 같이 저장된 데이터를 수정하는 경우 -> Mutation을 이용해 요청한다.

mutation : 저장된 데이터를 수정하기

subscription : 특정 이벤트가 발생 시 서버가 대응하는 데이터를 실시간으로 클라이언트에게 전송

무엇을 사용해야 할까?

RestAPI의 경우 모든 엔드포인트를 일일이 개발하고 여러 경우의 수를 대응해야 하기에 개발 속도가 상대적으로 느리고, GraphQL의 경우에는 원칙적으로 Multipart 방식의 전송이 허용되지 않기에 이미지, 영상 등의 처리에 굉장히 약한 모습을 보입니다.

그렇기 때문에 이러한 단점을 생각해서 적절하게 사용하는 것이 좋습니다.

유요한

발전하기 위한 공부

이전 포스트

기술 면접(Git)

다음 포스트