REST API

이번 포스팅의 주제는 REST API 입니다. 

 

REST API

그 전에 API라는 개념부터 알아봅시다.

API( Application Programming Interface)란 두 소프트웨어 간의 통신 방식을 모아놓은 것입니다.

REST API는 REST(Representational State Transfer)라는 아키텍처 스타일을 따르는 API입니다.

REST는 웹 서비스 개발에 사용되는 규칙과 원칙을 정의한 아키텍처 스타일로,

REST API는 이러한 규칙과 원칙을 준수하여 설계된 API를 의미합니다.

 

설계 원칙

REST API를 설계할 때 사용되는 설계 원칙은 6가지가 존재합니다.

 

• Client-Server: 클라이언트와 서버가 분리되어 있어야 하고, 이를 통해 각각의 역할을 독립적으로 진행할 수 있어야 합니다.
• Stateless: 요청 간에 클라이언트의 상태를 서버에 저장하지 않아야 하며, 각 요청은 서버가 필요한 모든 정보를 포함해야 합니다.
• Uniform Interface: 같은 요청에 대한 리소스는 항상 일
• Cacheable: 응답은 캐싱이 가능해야 하며, 클라이언트는 적절한 캐싱을 통해 캐시를 활용할 수 있어야 합니다.
• Layered System: 다중 계층으로 구성되어 클라이언트는 서버와 직접 통신하지만 중간 계층을 통해 간접적으로 통신할 수 있어야 합니다.
• Code-On-Demand (Optional): 서버에서 클라이언트로 코드를 전송하여 기능을 확장할 수 있는 선택적 기능입니다.

각각 규칙들을 조금 더 구체적으로 알아봅시다.

Client-Server

Client 와 Server가 서로 decoupling 되어 있어야 함을 의미합니다. 

 

예를 들어 서비스를 제공하는 회사에서 프론트와 백을 나눠 개발하는 경우 프론트는 API를 통해 백과 통신하고 이 결과를 프론트가 보여주게 됩니다. 두 소프트웨어는 결합하지 않고 API를 통해서만 통신합니다.

이런 형태의 통신은 개발을 진행함에 있어서도 굉장히 큰 도움이 되는데, 문서화만 잘 되어 있다면 프론트와 백엔드의 개발이 병렬로 진행될 수도 있다는 장점을 가집니다.

 

또 각 소프트웨어는 컴포넌트로 취급될 수 있고, 이 컴포넌트들은 다른 컴포넌트로 대체가 가능합니다.

 

Stateless

Stateless는 서버가 클라이언트의 상태를 저장하지 않겠다는 의미입니다.

클라이언트의 요청에는 응답에 필요한 모든 것들을 보내주어야 합니다.

 

Stateless의 핵심은 이 규칙을 만족한다는 것은 서버와 클라이언트 사이의 독립성을 보장한다는 것입니다.

서버에 요청량이 많거나 서버가 다운된다면 다른 서버를 새로 만들거나 기존의 다른 서버에 이 요청을 보내주면 됩니다. 만약 Stateless 하지 않다면 해당 요청은 특정 서버에 의존한다는 것이고 그렇게 되면 이 특정 서버가 다운되면 해당 요청을 처리할 수 있는 서버가 현 시점에 존재하지 않게됩니다.

하지만 Stateless가 보장된다면 위와 같은 문제점이 발생하지 않습니다.

 

Uniform Interface

Uniform Interface는 REST 아키텍처의 중요한 원칙 중 하나입니다. 이 원칙은 다음과 같은 특성을 포함하고 있습니다:

1. Identification of Resources (리소스 식별): 각 리소스는 고유한 URI를 통해 식별되어야 합니다. URI는 클라이언트가 리소스에 접근할 수 있는 위치를 나타내며, 각 리소스는 유일한 URI를 가져야 합니다.
2. Manipulation of Resources through Representations (리소스 조작): 클라이언트는 리소스에 대한 조작을 통해 리소스의 상태를 변경할 수 있어야 합니다. 이는 HTTP 메소드(GET, POST, PUT, DELETE 등)를 통해 이루어집니다.
3. Self-descriptive Messages (자기 서술적 메시지): 각 요청과 응답은 리소스에 대한 충분한 정보를 포함하여야 합니다. 이는 HTTP 헤더와 바디를 이용해 데이터와 메타데이터를 포함하고 있습니다.
4. Hypermedia as the Engine of Application State (HATEOAS): 서버는 클라이언트에게 리소스와 관련된 다음 가능한 액션들에 대한 링크를 제공하여, 클라이언트가 상태 전이를 이해할 수 있게 합니다.

API 디자인에서는 모든 리소스에 대해 일관된 URI 패턴과 HTTP 메소드 사용법을 정의하고, 각 요청과 응답은 명확하게 리소스와 그 상태에 대한 정보를 전달해야 합니다.

 

Uniform Interface의 목적은 클라이언트와 서버 간의 인터페이스를 일관되게 유지하여 상호 운용성을 향상시키고, 클라이언트와 서버의 독립성을 보장하는 것입니다.

 

Cacheable

단순히 캐싱을 지원할 수 있어야 함을 의미합니다.

 

Layered System

HTTP를 사용하는 시스템들은 생각보다 다양합니다. 실제 사용자와 서비스 제공 서버 간에는 다양한 HTTP 서버들이 존재할 수 있고 서로 계층적 구조를 이루는데, 이 사실은 두 소프트웨어 간의 통신에 관여하지 않아야 합니다.

 

Code-On-Demand (Optional)

선택사항으로 전달되는 응답 데이터가 동적인 것을 의미합니다. 실행 가능한 코드를 클라이언트가 다운받아 실행하는 형태입니다.

 

정리

REST API는 웹 서비스 개발에 사용되는 API에 대한 규약입니다. REST API를 잘 정의해 두면 애플리케이션 간의 독립성이 보장되어 원할한 개발 및 운용/유지보수가 가능합니다.