REST API와 RESTful API

😀우리가 코드를 작성할 때 과연 지금 작성한 내 코드가 RESTful 한가?에 대해서 계속 고민하고 리펙토링해 간다. 어렴풋이 RESTful함이 명세서 대로 주소를 잘 작성하고, GET•POST 등 메소드를 잘 연결 지어서 API를 작성하는 것이라고 알고 있었는데 정확히 RESTful API가 무엇인지 알아보자

RESTful API 는 REST API원칙을 잘 지켜서 작성한 API를 의미한다. 그렇다면 REST API는 무엇일까?

REST API란?

REST API는 Representational State Transfer API의 약자로 웹 서비스 간에 데이터를 전송하기 위한 아키텍처 스타일(or API 디자인패턴)을 의미한다.

HTTP 프로토콜을 기반으로 URI를 사용하여 데이터를 주고받는 클라이언트와 서버 간의 통신을 위한 표준화된 방식이다.

REST API는 특정한 설계원칙에 따라서 HTTP 메서드를 이용하여 리소스를 생성, 조회, 수정, 삭제하는 CRUD 작업을 수행하는 API를 작성한다.

REST API의 설계 원칙

😀REST API를 설계하기 위해서는 아래의 설계원칙에 맞춰 구성할 필요가 있다.

클라이언트-서버 구조

클라이언트와 서버가 독립적으로 개발되고 유지보수될 수 있도록 설계되어야 한다.

• 클라이언트는 오직 URIs 리소스만 알아야하며 클라이언트와 서버의 인터페이스가 변경되지 않는 한, 이 둘은 독립적으로 개발되거나 대체될 수 있게 유지해야한다.
• 클라이언트는 서버에 요청을 보내고, 서버는 응답을 반환한다.

무상태성 (Stateless)

서버는 클라이언트의 상태 정보를 저장하지 않아야 한다.

• 클라이언트의 모든 요청에 대한 응답은 독립적으로 처리되어야 한다.
• 서버는 HTTP 요청에 대한 어떤 것도 저장하지 않는다. 컨텍스트를 유지해야하는 세션, 인증과 인가에 대한 정보 또한 클라이언트에만 보관되며, 각 요청 시 해당 정보를 모두 포함하여 서버에 요청한다.

캐시 처리 가능 (Cacheable)

클라이언트는 서버의 응답을 캐시할 수 있어야 한다.

• 서버는 Response cache-control 헤더에 해당 요청이 캐싱이 가능한 지에 대한 여부를 제공해야 한다.
  이를 제공한다면 클라이언트는 Response를 캐싱하여 서버와 클라이언트 간의 상호작용을 줄이고, 성능과 서버 가용성을 늘릴 수 있다.

계층형 구조 (Layered System)

다중 계층 구조를 가질 수 있도록 허용한다.

• REST서버는 API 제공, 클라이언트는 사용자 인증이나 컨텍스트(세션, 로그인 정보) 등을 직접 관리하는 구조로 각각의 역할을 확실하게 구분한다.

인터페이스 일관성(Uniform Interface)

API의 인터페이스는 일관적이고 자기서술적이어야 한다.

• 클라이언트는 API 인터페이스만 보고도 API를 이해하고 사용할 수 있어야 한다.

• 인터페이스의 일관성을 지키기 위해서 아래의 항목들을 생각해야한다.

  • 자원 식별 (Resource Identification): 각 리소스는 URI로 식별되어야 합니다. URI는 계층적인 구조를 가지며, 슬래시(/)로 구분된다.

  • 메시지 교환 (Message Exchange): REST API는 HTTP 프로토콜을 기반으로 동작한다. 클라이언트와 서버 간에는 메시지를 교환하며, 메시지는 클라이언트의 요청과 서버의 응답으로 구성된다.

  • 자기 서술적 메시지 (Self-descriptive Messages): 메시지는 자기 서술적이어야 한다. 즉, 메시지에는 메시지의 내용과 처리 방법에 대한 정보가 포함되어야 한다.

  • 하이퍼미디어를 활용한 애플리케이션 상태 전이 (Hypermedia-driven Application State Transfer): 서버는 하이퍼미디어를 이용하여 애플리케이션 상태 전이를 수행할 수 있어야 한다. 클라이언트는 서버로부터 받은 하이퍼미디어를 이용하여 다음 상태로 전이할 수 있어야 한다.

REST API가 가지는 장단점

REST API는 개발에 있어서 효율적인 성능을 가진다. 한편으로는 이 효율성의 증가를 위해 보완 해야하는 단점 또한 발생한다.

장점

• 단순한 인터페이스
  REST API는 HTTP 프로토콜을 기반으로 하며, 요청 메소드(GET, POST, PUT, DELETE)와 URI(Uniform Resource Identifier)만으로 자원을 조작할 수 있다. 이를 통해 개발자는 복잡한 인터페이스를 작성하지 않아도 된다.

• 높은 확장성
  REST API는 URI를 통해 자원(Resource)을 식별하며, HTTP 요청 메소드를 사용하여 자원을 조작한다. 이를 통해 새로운 자원이나 요청 메소드를 추가하여 API를 확장할 수 있다.

• 상태를 유지하지 않음
  REST API는 설계원칙에서 말했듯이 상태를 유지하지 않는다. 클라이언트와 서버 간의 상호작용에서 상태 정보를 전송하지 않습니다. 이를 통해 서버의 부하를 줄일 수 있으며, 서비스의 확장성과 안정성을 향상시킬 수 있다.

• 다양한 클라이언트 지원
  REST API는 HTTP 프로토콜을 기반으로 하므로, 다양한 클라이언트(웹 브라우저, 모바일 애플리케이션 등)에서 쉽게 사용할 수 있다.

• 캐시 기능 지원
  REST API는 HTTP 프로토콜의 캐시 기능을 활용할 수 있다. 이를 통해 클라이언트와 서버 간의 대역폭 사용량을 줄이고, API 성능을 향상시킬 수 있다.

단점

• 정확한 구현 필요
  REST API는 HTTP 프로토콜을 기반으로 하므로, URI, HTTP 메소드, 응답 코드 등을 정확하게 구현해야 한다. 그렇지 않으면 클라이언트와 서버 간의 상호 운용성에 문제가 발생할 수 있다.

• 보안 문제
  REST API는 URI에 민감한 정보(패스워드, 세션 ID 등)를 전송할 수 있으므로, 보안적인 문제가 발생할 수 있다. 이러한 문제를 해결하기 위해서는 HTTPS와 같은 보안 프로토콜을 사용해야 한다.

• 불필요한 데이터 전송
  REST API는 클라이언트와 서버 간의 상태를 유지하지 않으므로, 요청 시마다 모든 데이터를 전송해야 한다. 이는 데이터 전송량이 증가하여 성능에 영향을 미칠 수 있다.

RESTful API

REST API 설계원칙에 따라 작성한 API를 RESTful한 API라고 말한다.

😀특히나 다섯번째 항목인 인터페이스 일관성(Uniform Interface) 이 RESTful함의 큰 관건이 된다. 다른 부분은 구조적이나 기능적으로 처리하는 부분이지만, 인터페이스 일관성(Uniform Interface) 만큼은 개발자가 직접 유념하며 코드를 작성해야 되기 때문이다.

API인터페이스의 일관성을 지키기 위한 방법은 이전에 작성한 CRUD의 가독성을 위한 API컨벤션 포스팅과 굉장히 유사한 부분이 많다. 이 포스팅에서 몇개더 추가될 뿐이다. 좀 더 자세한 사항을 알고싶다면 본 포스팅 아래의 출처를 확인해보자.

REST API vs SOAP, GraghQL

😀REST API는 HTTP 프로토콜을 기반이라는 큰 특징을 가진 웹 API 패턴이다. 일반적으로 REST API 비교되는 API에 대해서 알아보자

SOAP API

SOAP(Simple Object Access Protocol) API는 웹 서비스를 구현하기 위한 통신 프로토콜 중 하나이다.

• SOAP API는 REST API와 자주 비교되지만, 패턴이 아닌 프로토콜 그 자체를 의미하기 때문에 본질적으로 다른기술이라 세부적인 비교를 하기에는 어렵다.

• SOAP은 XML 기반의 메시지 교환 프로토콜로, HTTP, HTTPS, SMTP 등 다양한 통신 프로토콜 위에서 동작할 수 있다.

• SOAP API는 REST API와는 달리, 모든 요청과 응답이 XML 형식으로 이루어지며, WSDL(Web Services Description Language) 파일을 사용하여 API의 구조와 사용 가능한 메소드를 정의한다. 따라서, SOAP API는 REST API와 달리 구현이 복잡하고, 데이터 전송량이 많아질 수 있다.
  하지만, SOAP API는 보안 기능이 강화되어 있고, 오류 처리가 명확하며, 다양한 통신 프로토콜을 지원하여 다양한 환경에서 동작할 수 있다.

😀SOAP는 보안이나 메시지 전송 등에 있어서 REST보다 더 많은 표준들이 정해져있기 때문에 조금 더 복잡하다. 대신 SOAP 표준에는 성공/반복 실행 로직이 규정되어 있기 때문에, SOAP API를 통해서 통신을 할 때 처음부터 끝까지 신뢰성을 제공할 수 있다.

GraghQL API

GraphQL은 API용 오픈 소스 데이터 쿼리 및 조작 언어이며 기존 데이터로 쿼리를 수행하기 위한 런타임이다.

• REST API와 마찬가지로, 클라이언트와 서버 간의 통신을 위해 사용된다.

• GraphQL API는 REST API와는 다른 쿼리 언어를 사용한다. 클라이언트는 필요한 데이터를 쿼리로 요청하고, 서버는 해당 쿼리를 해석하여 필요한 데이터만을 응답한다. 이를 통해 클라이언트는 필요한 데이터만을 받아오고, 서버는 불필요한 데이터를 제공하지 않으므로, 데이터 전송량과 응답 시간을 줄일 수 있다.

• REST API는 주로 CRUD(Create, Read, Update, Delete) 작업에 사용된다. 반면, GraphQL API는 클라이언트가 필요한 데이터를 직접 지정할 수 있으므로, CRUD 작업 이외에도 다양한 작업에 사용할 수 있다.

• REST API는 여러 개의 엔드포인트를 사용하고, 각 엔드포인트는 특정 리소스를 나타냅니다. 반면, GraphQL API는 단일 엔드포인트를 사용하고, 클라이언트는 필요한 데이터를 쿼리로 요청한다.

참고자료(출처)
What is REST
RESTful API를 위한 6가지 원칙과 네이밍
REST API 설계 원칙
티스토리 ISSAC 개발일기 포스팅 API란 개념,종류(REST API, SOAP API),역사 쉽게정리
hygraph GraphQL Vs. REST APIs