Restful API

등장 배경

2000년에 Roy Fielding의 박사 학위 논문에서 처음 제안되었습니다. 그는 이 논문에서 웹을 운영하는 기본 원칙을 명시하고, 이를 REST (Representational State Transfer)라고 명명했습니다. 이 원칙들은 HTTP와 같은 기존 프로토콜을 사용하여 웹 서비스를 설계하는 방법을 제시하였습니다.

그 후 웹의 발전과 함께 RESTful API는 점점 더 인기를 얻기 시작했습니다. 이는 RESTful API가 웹의 자원을 효과적으로 사용하며, 간단하고 직관적인 인터페이스를 제공하기 때문입니다. 또한, RESTful API는 상태를 저장하지 않는 설계로 인해 확장성이 뛰어나, 대규모 시스템에서도 효과적으로 동작합니다.

따라서 RESTful API는 2000년대 초반부터 웹 서비스를 구축하는데 널리 사용되어 왔습니다. 이는 다양한 웹 기반 서비스들이 이러한 REST 원칙을 따르는 API를 제공하며, 이를 통해 외부 개발자들이 해당 서비스의 기능을 활용할 수 있게 하였기 때문입니다.

RESTful API의 주요 특징

Resource Oriented

Resource(자원)에 기반한 설계방식입니다.

웹 상에서 각 자원은 고유한 URI로 식별됩니다.

URI는 자원의 위치를 나타내며, HTTP 메서드를 통해 해당 자원에 대한 동작을 정의합니다.

• GET: 자원 조회
• POST: 자원 생성
• PUT, PATCH: 자원 업데이트
  • PUT: 전체 리소스 교체
  • PATCH: 리소스의 일부만 수정
• DELETE: 자원 삭제

Stateless

각 요청은 서버가 이해하고 처리하는 데 필요한 모든 정보를 담아야 합니다.

서버는 클라이언트의 이전 요청에 대한 정보를 저장하지 않습니다.

이 원칙은 서버의 부하를 줄이고 확장성을 향상시킵니다.

Cacheable

응답을 캐시할 수 있습니다.

일반적으로 클라이언트가 자주 접근하는 데이터를 로컬에 캐싱하여, 동일한 요청이 발생한 경우 서버에 다시 요청하지 않고 캐싱된 데이터를 사용합니다.

캐싱이 가능한지 여부는 HTTP 헤더를 통해 통신됩니다.

• Cache-Cotrol
  • no-cache: 클라이언트나 서버가 응답을 캐시하지 못하게 합니다.
  • no-store: 요청이나 응답이 어떤 형태로든 캐시되는 것을 금지합니다.
  • public: 응답이 모든 사용자에게 공개되며, 일반적으로 어떤 사용자든 캐시할 수 있음을 나타냅니다.
  • private: 응답이 특정 사용자에게만 해당되며, 일반적으로 특정 사용자만 캐시할 수 있음을 나타냅니다.
  • max-age=[seconds]: 캐시가 얼마나 오래 유효한지를 초 단위로 나타냅니다.

Client-Server 구조

REST 아키텍처는 클라이언트와 서버의 역할을 분리합니다.

따라서 각각이 독립적으로 발전하고 변경될 수 있습니다.

클라이언트는 자원에 대한 요청을 보내고 응답을 받는 역할을 하며, 서버는 자원을 관리하고 클라이언트의 요청에 응답하는 역할을 합니다.

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

HTTP 표준 메서드를 사용하고 리소스를 URI로 식별함으로써 인터페이스를 단순하고 일관성있게 만듭니다.

Layered System

REST 아키텍처는 여러 계층으로 구성될 수 있습니다.

클라이언트는 직접 통신하는 층에만 연결되며, 다른 층의 존재를 알 필요가 없습니다.