[책집필] REST API

오늘의 기술면접 주제는 REST API 에 대해서 다룬다.

1. REST API

---

1-1. 30초 답변

REST API는 클라이언트와 서버 간의 통신 방식을 정의한 REST(REpresentational State Transfer)라는 아키텍처 스타일을 따르는 웹 API입니다. 이 중에 REST 아키텍처 스타일을 완벽하게 준수하는 API의 경우 RESTful API라고 부릅니다. REST API는 HTTP 요청을 통해 클라이언트와 서버 간에 리소스를 주고받을 수 있습니다. 리소스는 JSON, XML, HTML 등의 다양한 형식으로 표현될 수 있으며, URI(Uniform Resource Identifier)로 식별됩니다. REST API는 상태가 없으므로 각 요청이 독립적이고 자기 서술적인 특징을 가집니다. 또한, 캐싱, 계층화 시스템, 주문형 코드(Code on Demand) 등의 특징을 통해 시스템의 성능과 확장성을 향상할 수 있습니다.

이미지 출처: REST APIs Explained

 

1-2. 상세 답변

REST(REpresentational State Transfer)는 기존 WWW(World Wide Web)의 문제점이었던, 클라이언트와 서버 간 결합도가 높고 자원관리가 어렵다는 문제점을 해결하면서, HTTP 호환성을 유지하며 웹을 보다 잘 사용하기 위한 방법으로 고안되었습니다.

REST API는 웹에서 컴포넌트 간의 상호작용을 위한 6 가지 제약조건(특징)을 가집니다.

클라이언트-서버 구조: 클라이언트는 요청을 발생시키고, 서버는 REST API를 제공함으로써 요청에 대해 반응하는 구조입니다. 클라이언트와 서버가 분리되어 서로의 독립성과 확장성을 높입니다.

무상태성(Stateless): 클라이언트의 상태 정보를 서버에 저장하지 않고, 클라이언트는 각 요청에 필요한 정보를 모두 담아서 전송합니다. 이렇게 하면 서버의 부하를 줄이고 성능을 높일 수 있습니다.

캐시 가능성(Cacheable): HTTP 프로토콜의 캐싱 기능을 활용하여 자주 사용되는 데이터를 캐시에 저장하고 재사용할 수 있습니다. 이를 통해 서버측의 네트워크 트래픽을 줄이고, 클라이언트 측의 응답 속도를 높일 수 있습니다.

계층화된 시스템(Layered System): 클라이언트와 서버 사이에 여러 개의 중간 계층(로드 밸런서, 프록시, 게이트웨이 등)을 두어 보안, 로드 밸런싱, 암호화 등의 기능을 추가할 수 있습니다. 클라이언트는 중간 계층의 존재를 알 수 없습니다.

주문형 코드(Code on Demand): 클라이언트의 기능을 확장하거나 변경하기 위해 서버에서 클라이언트에 실행 가능한 코드를 전송할 수 있습니다. 주문형 코드는 플러그인*(Plugin)*의 형태가 대표적이며 시스템 전체적으로 적용되었을 때 성능 이슈가 발생할 가능성이 있어 선택적인 항목입니다.

균일한 인터페이스(Uniform Interface): 자원을 식별하고 조작하는 방식이 통일되어 있어서 일관성과 단순성을 제공합니다. 균일한 인터페이스는 다시 하위 4 가지 제약 조건을 가집니다.

리소스 식별: 리소스란 웹에서 식별 가능하고 접근 가능한 모든 것을 의미하며 각 리소스는 고유한 URI로 식별 됩니다.

리소스 조작: 클라이언트가 서버로부터 받은 표현을 통해 리소스를 조작할 수 있습니다. 표현은 리소스의 상태와 속성을 나타내는 데이터 형식(JSON, XML, HTML 등)입니다. 리소스의 상태(State)는 특정 시점에 리소스가 가지고 있는 정보나 데이터를 의미합니다.

자기 서술적 메시지(Self-descriptive Message): 요청과 응답 메시지에 필요한 정보(메서드, 상태 코드, 콘텐츠 타입 등)가 모두 포함되어 있어서 메시지만으로 수행할 작업 이해할 수 있습니다.

HATEOAS(Hypermedia As The Engine Of Application State): 클라이언트가 현재 리소스와 연관된 다른 리소스에 접근할 수 있는 하이퍼미디어(하이퍼링크) 정보를 제공합니다.

2. 꼬리질문

---

2-1. 꼬리질문: RESTful API와 REST API의 차이점에 대해 설명해주세요.

REST API는 일반적으로 REST 아키텍처 스타일을 따르려고 하는 웹 API를 말하며, RESTful API는 특별히 REST 아키텍처 스타일을 완벽하게 준수하는 API를 말합니다.

REST API는 균일한 인터페이스의 모든 제약 조건을 지키지 않아도 됩니다. 즉, 균일한 인터페이스의 하위 제약조건 중 하나인 HATEOAS를 구현하지 않아도 REST API라고 할 수 있습니다. 반면에 RESTful API는 균일한 인터페이스의 모든 원칙을 지켜야 합니다. REST API는 개발자의 해석에 따라 다양한 방식으로 구현될 수 있습니다. RESTful API는 정해진 규칙에 따라 일관된 방식으로 구현되어야 합니다. 따라서 RESTful API는 REST API의 장점을 가짐과 동시에 표준 인터페이스 제공하여 일관성과 호환성을 확보할 수 있습니다.

 

2-2. 꼬리질문: REST API 의 장단점

REST API 의 장점은 다음과 같습니다.

  독립성: 언어와 플랫폼에 독립적입니다. HTTP 프로토콜과 표준화된 데이터 형식만 지원한다면 어떤 언어나 플랫폼에서도 REST API를 사용할 수 있습니다.

  직관성: 간단하고 직관적입니다. URI로 리소스를 식별하고, HTTP 메소드로 행위를 표현하며, 다양한 형식으로 데이터를 주고받습니다. 별도의 문서나 규약이 필요하지 않습니다.

  확장성: 유연하고 확장성이 높습니다. 리소스와 표현, 요청과 응답이 분리되어 있으므로 서버와 클라이언트의 구현이 독립적입니다. 즉, 서버의 기능이 변경되어도 클라이언트에 영향을 주지 않고, 클라이언트의 요구사항이 변경되어도 서버에 영향을 주지 않습니다. 또한, 중간 계층을 추가하거나 제거하면서 시스템을 쉽게 확장하거나 변경할 수 있습니다.

REST API 의 단점은 다음과 같습니다.

  호환성:표준이 없습니다. REST는 아키텍처 스타일일 뿐이므로, 개발자들은 필요에 따라 다른 방식으로 구현할 수 있습니다. 이는 일관성과 호환성을 떨어뜨리고, 재사용성과 유지보수성을 어렵게 할 수 있습니다.

  성능 이슈: REST API는 상태가 없으므로, 각 요청에 필요한 모든 정보를 포함하여 보내야 합니다. 이는 네트워크 오버헤드를 증가할 수 있습니다. 또한, JSON이나 XML과 같은 형식은 데이터의 크기가 커지거나 복잡해지면 파싱하는데 시간이 오래 걸릴 수 있습니다.

  보안 이슈: REST API는 HTTP 프로토콜을 사용하므로, 데이터가 암호화되지 않은 상태로 전송될 수 있습니다. 이는 중간자 공격*(man-in-the-middle attack)* 등의 위험에 노출될 수 있습니다. 따라서 HTTPS나 토큰 기반 인증*(token-based authentication)* 등의 방법을 사용하여 보안을 강화해야 합니다.

 

2-3. 꼬리질문: REST API 의 사용 사례

  웹 서비스: 웹 서비스란 네트워크 상에서 서로 다른 시스템 간에 상호작용할 수 있도록 제공되는 소프트웨어 시스템입니다. 웹 서비스는 SOAP(Simple Object Access Protocol)이나 REST와 같은 방식으로 구현될 수 있습니다. REST 방식의 웹 서비스는 RESTful 웹 서비스라고 부르며, 많은 인터넷 기업들이 제공하고 있습니다. 예를 들어, 구글, 페이스북, 트위터, 깃허브 등이 RESTful 웹 서비스를 제공합니다.

  마이크로서비스: 마이크로서비스란 하나의 큰 애플리케이션을 작고 독립적인 여러 개의 서비스로 분리하여 개발하고 운영하는 아키텍처 패러다임입니다. 마이크로서비스는 각각의 서비스가 자신의 비즈니스 로직과 데이터를 가지고 있으며, REST API를 통해 서로 통신합니다. 마이크로서비스는 서비스의 재사용성과 확장성을 높이고, 장애의 영향을 최소화하고, 배포와 유지보수를 용이하게 합니다.

  웹 애플리케이션: 웹 애플리케이션은 웹 브라우저에서 동작하는 애플리케이션입니다. 웹 애플리케이션은 일반적으로 프론트엔드와 백엔드로 구성됩니다. 프론트엔드는 HTML, CSS, 자바스크립트 등으로 구현되며, 사용자 인터페이스를 담당합니다. 백엔드는 자바, 파이썬, 루비 등으로 구현되며, 비즈니스 로직과 데이터베이스를 담당합니다. 프론트엔드와 백엔드는 REST API를 통해 데이터를 주고받습니다.

3. 사전개념

---

3-1. REST 란?

REST(Representational State Transfer)는 로이 필딩(Roy Fielding)이 처음으로 제안한 아키텍처 스타일입니다. REST는 웹(분산 하이퍼미디어 시스템)에서 컴포넌트 간의 상호작용을 위한 제약 조건들의 집합으로 정의됩니다. REST는 프로토콜이나 표준이 아니라 지침이기 때문에 개발자들은 필요에 따라 다양한 방식으로 구현할 수 있습니다.

 

3-2. API 란?

API(Application Programming Interface)는 애플리케이션 또는 클라이언트와 서버 간에 데이터나 기능을 공유하기 위한 인터페이스입니다. API를 통해 개발자들은 복잡한 로직이나 저수준의 세부사항 없이도 다른 애플리케이션의 리소스나 서비스를 활용할 수 있습니다. 추가적으로 말하자면 DOM APIs, Location APIs, contextAPIs 등 라이브러리나 프레임워크에서 제공하는 기능을 API라고 부르기도 합니다.

 

3-3. Applet

  애플릿(applet)은 플러그인의 하나로서 전용 위젯 엔진이나 더 큰 프로그램 범위 내에서 실행되는 특정한 작업을 수행하는 조그마한 응용 프로그램을 의미합니다. 독립적으로 실행할 수 없으며 작은 기능을 가지고 있습니다. 웹 브라우저, 제어판 같은 다른 프로그램에서 실행되는 소프트웨어 구성 요소로 볼 수 있습니다.

 

3-4. Overhead

  오버헤드는 어떤 처리를 하기 위해 들어가는 간접적인 처리 시간, 메모리 등 추가적으로 사용되는 컴퓨터 자원을 지칭하는 용어입니다. 예를 들어 A 작업의 평소 처리 시간이 10초가 걸리지만 안정성을 고려하여 부가적인 B 작업의 처리를 추가한 결과로 처리시간이 15초 걸렸다면, 오버헤드는 5초가 됩니다.