RESTful API는 Representational State Transfer (REST) 원칙을 따르는 API로, 클라이언트와 서버 간의 통신 방식을 정해주는 아키텍처 스타일입니다. RESTful API는 HTTP 프로토콜을 기반으로 하며, 특정한 원칙과 규칙을 따라 데이터를 주고받기 때문에 확장성, 유지보수성, 가독성에서 이점을 가집니다.
RESTful API는 일관성 있는 엔드포인트와 HTTP 메서드를 사용하여 간결하고 직관적인 구조를 제공합니다.
들어가기 전에...
🤔 REST API와 RESTful API의 차이는 뭘까?
1. REST (Representational State Transfer)
- 개념: REST는 웹 아키텍처의 스타일이자 설계 원칙을 나타내는 용어로, 2000년대 초반에 로이 필딩(Roy Fielding)이 제안한 개념입니다.
- 원칙: REST는 웹 기반 시스템을 설계할 때 따를 수 있는 일련의 원칙으로, 주로 클라이언트와 서버 간의 무상태성, 리소스 기반 설계, 캐시 가능성, 일관된 인터페이스 등의 원칙을 포함합니다.
- 특징: REST는 클라이언트가 서버에 필요한 리소스를 요청하고 이를 전달하는 방식을 단순화하여 확장성과 유지보수성을 높여주는 설계 방식입니다.
2. REST API
- 정의: REST 아키텍처 스타일을 따르는 응용 프로그램 인터페이스(API)를 의미합니다.
- 특징: REST의 원칙에 기반하여 설계된 API를 가리키며, 일반적으로 HTTP 메서드(GET, POST, PUT, DELETE 등)를 사용해 특정 리소스를 CRUD 작업할 수 있도록 합니다.
- 예시: GET /users/1는 ID가 1인 사용자를 가져오는 REST API 엔드포인트입니다.
3. RESTful API
- 정의: REST 원칙을 충실히 준수하여 설계된 API를 의미합니다. 즉, 단순히 REST 아키텍처를 기반으로 한 API가 아니라, REST의 모든 원칙과 제약을 최대한 지켜서 구현한 API를 의미합니다.
- REST API와의 차이점: RESTful API는 REST 아키텍처 원칙을 더 엄격하게 따르려는 점에서 차이가 있습니다. REST API라는 용어는 REST의 일부 원칙만 지켜도 사용하는 경우가 많지만, RESTful API는 무상태성, 일관된 인터페이스, 리소스 중심 설계 등 REST의 제약 조건을 더 철저하게 준수하려는 것입니다.
요약
- REST API는 REST 원칙을 일부라도 따르는 API를 가리키며, RESTful API에 비해 상대적으로 덜 엄격한 REST 준수를 의미할 수 있습니다.
- RESTful API는 REST의 모든 원칙과 제약 조건을 가능한 한 철저히 따르는 API를 의미합니다.
결론적으로, 모든 RESTful API는 REST API지만, 모든 REST API가 반드시 RESTful한 것은 아닙니다. RESTful API는 REST의 원칙을 최대한 지켜 설계된 API를 가리키며, REST API보다 더 REST의 규칙을 엄격히 준수하려는 의도를 내포하고 있습니다.
REST의 주요 원칙
1. Stateless (무상태성)
클라이언트의 각 요청은 독립적이어야 하며, 서버는 각 요청을 개별적으로 처리합니다. 즉, 서버는 요청 간의 상태를 기억하지 않으며, 필요한 모든 정보는 요청 안에 포함됩니다.
2. Client-Server Architecture (클라이언트-서버 구조)
클라이언트와 서버는 서로 독립적입니다. 클라이언트는 요청을 통해 데이터를 요청하고, 서버는 데이터를 제공하는 역할만을 합니다. 이를 통해 서로의 역할을 분리하고, 독립적으로 확장 가능하게 만듭니다.
3. Uniform Interface (일관된 인터페이스)
모든 리소스에 대해 일관된 URI 형식을 사용하고, HTTP 메서드를 활용하여 리소스를 CRUD (Create, Read, Update, Delete) 방식으로 조작합니다.
- GET: 데이터 조회
- POST: 새로운 데이터 생성
- PUT/PATCH: 데이터 업데이트
- DELETE: 데이터 삭제
4. Resource Identification (리소스 식별)
REST에서는 각각의 리소스가 고유한 URI로 식별됩니다. 예를 들어, /users/123는 ID가 123인 사용자 리소스를 의미합니다.
5. Representation (표현)
서버는 데이터를 JSON, XML 등 다양한 형식으로 응답할 수 있습니다. 클라이언트는 이를 받아 필요한 형식으로 변환하여 사용할 수 있습니다.
6. Cacheable (캐싱 가능)
REST API 응답에는 캐시가 가능해야 합니다. 이를 통해 서버에 부담을 줄이고, 요청 속도를 향상시킬 수 있습니다.
7. RESTful API의 장점
- 확장성: 리소스를 추가하거나 확장하기 쉽습니다.
- 유지보수성: 일관된 규칙을 따르기 때문에 코드의 가독성과 유지보수성이 높아집니다.
- 유연성: JSON, XML 등 다양한 표현 방식을 지원하므로 여러 플랫폼과 쉽게 연동할 수 있습니다.
RESTful API는 클라이언트와 서버 간의 통신을 간단하고 효율적으로 만들어 주며, 현재 웹 API 설계에서 널리 사용되는 방식입니다.
예시: CRUD (Create, Read, Update, Delete)
가상의 사용자 관리 API
기본 URL: https://api.example.com/users
1. 사용자 조회 (GET)
- 모든 사용자 조회
- HTTP Method: GET
- Endpoint: https://api.example.com/users
설명: 모든 사용자 정보를 가져옵니다.
응답 예시:
[
{"id": 1, "name": "Alice", "email": "alice@example.com"},
{"id": 2, "name": "Bob", "email": "bob@example.com"}
]
- 특정 사용자 조회
- HTTP Method: GET
- Endpoint: https://api.example.com/users/1
설명: ID가 1인 사용자 정보를 가져옵니다.
응답 예시:
{"id": 1, "name": "Alice", "email": "alice@example.com"}
2. 사용자 생성 (POST)
- 새로운 사용자 추가:
- HTTP Method: POST
-Endpoint: https://api.example.com/users
- Request Body:
{"name": "Charlie", "email": "charlie@example.com"} 설명: 새로운 사용자를 생성합니다.
응답 예시:
{"id": 3, "name": "Charlie", "email": "charlie@example.com"}
3. 사용자 수정 (PUT/PATCH)
-
사용자 정보 수정:
- HTTP Method: PUT 또는 PATCH
- Endpoint: https://api.example.com/users/1
- Request Body:{"name": "Alice Smith", "email": "alice.smith@example.com"}
설명: ID가 1인 사용자의 정보를 업데이트합니다.
응답 예시:
```javascript
{"id": 1, "name": "Alice Smith", "email": "alice.smith@example.com"}4. 사용자 삭제 (DELETE)
- 사용자 삭제:
- HTTP Method: DELETE
- Endpoint: https://api.example.com/users/1
설명: ID가 1인 사용자를 삭제합니다.
응답 예시:
{"message": "User deleted successfully"}