REST API

• 웹에서 사용되는 데이터나 자원(Resource)을 HTTP URI로 표현하고, HTTP 프로토콜을 통해 요청과 응답을 정의하는 방식
• REST 아키텍처 스타일을 따르는 API의 설계 가이드라인이다.

구글 REST API 가이드

REST 아키텍처 스타일

1. 자원 중심적

• 각 URL 경로(엔드포인트)는 고유한 식별자를 가진 자원을 나타낸다.

2. HTTP 메서드 활용

• HTTP 프로토콜의 메서드(GET, POST 등)를 활용하여 자원을 조작한다.

3. 명시적인 상태 전달

• HTTP 상태 코드(200 OK, 404 Not Found)를 통해 표현한다.

4. 자기서술적 메시지

• 메시지 자체가 의미를 담고 있어 클라이언트가 추가적인 문서나 상태를 추측하지 않고도 이해할 수 있어야 한다.

5. 하이퍼미디어 활용

• 링크를 통해 리소스 간의 관계를 명시하고, 이를 활용하여 클라이언트는 API를 탐색하고 상호작용할 수 있다.

REST 성숙도 모델

• REST API를 작성할 때 지켜야 할 규칙
• REST 아키텍처 스타일을 발전시킬 수 있는 지표, 단계적 진화 모델이다.
• 3단계까지 지키기 어렵기 때문에 2단계까지만 적용해도 좋은 API 디자인이라고 볼 수 있다.

0단계(Pre-REST)

• API는 전통적인 웹 서비스 스타일이다.
• URI 식별자가 없거나 일관성이 없다.
• 모든 조작은 주로 POST 메서드로 처리한다.
• 상태 전달을 위한 메커니즘이나 상태 코드가 없다.

1단계(Resource-Based)

• API를 리소스 중심적으로 설계하여 개별 리소스를 식별하고 조회할 수 있다.
• GET 메서드를 사용하여 리소스를 조회한다.
• 리소스에 대한 고유한 URI 식별자를 갖습니다.
• 기능 중심적 설계가 유지될 수 있다.

2단계(HTTP Verbs)

• API를 리소스 중심적으로 설계하여 개별 리소스를 식별하고 조회할 수 있다.
• HTTP 메서드(GET, POST, PUT, DELETE)를 적절하게 활용하여 리소스를 생성, 조회, 수정, 삭제한다.
• 상태 전달을 위해 HTTP 상태 코드를 사용한다.
• 리소스 중심적 설계가 강조된다.

3단계(HATEOAS)

• API를 리소스 중심적으로 설계하여 개별 리소스를 식별하고 조회할 수 있다.
• HTTP 메서드(GET, POST, PUT, DELETE)를 적절하게 활용하여 리소스를 생성, 조회, 수정, 삭제한다.
• 상태 전달을 위해 HTTP 상태 코드를 사용한다.
• Hypermedia로 리소스 간의 관계와 조작 가능한 링크를 표현한다.

Open API

• 공개적으로 문서화되어 외부 개발자나 기업이 해당 API를 사용하여 애플리케이션, 웹 서비스, 모바일 앱 등을 개발하도록 허용하는 API
• 다른 개발자나 기업이 해당 플랫폼, 서비스, 소프트웨어 등을 확장하고 통합할 수 있도록 API를 제공하는 것
• API마다 정해진 이용 수칙과 제한사항(가격, 정보의 제한 등)이 있을 수 있다.

API Key

• API를 보호하고 인증하기 위해 사용되는 키
• API 사용량 제한, 권한 부여 등의 제어도 가능하다.