1. REST API와 RESTful API 비교
1.1 REST API란?
REST API는 REST(Representational State Transfer) 아키텍처 스타일을 따르는 API(Application Programming Interface)를 의미합니다. REST는 웹에서 리소스(데이터)를 효율적으로 전송하는 방식으로, 주로 HTTP를 기반으로 합니다. REST API는 클라이언트와 서버 간의 통신을 효율적으로 설계하고 리소스(데이터)를 HTTP 메서드를 통해 전달하는 방식입니다.
1.2 RESTful API란?
RESTful API는 REST 아키텍처의 원칙을 완벽하게 준수하는 API를 의미합니다. RESTful API는 REST의 6가지 기본 원칙을 따르며, 이를 통해 서버와 클라이언트 간의 통신을 일관되고 효율적으로 관리할 수 있습니다. RESTful이라는 용어는 API가 REST의 규칙을 따를 때 사용되며, 단순히 REST API라는 이름을 붙인다고 해서 RESTful한 API가 되는 것은 아닙니다.
2. REST API와 RESTful API의 차이점
- REST API는 REST를 사용하여 API를 설계한 모든 API를 의미합니다. 그러나 RESTful API는 REST의 원칙을 엄격하게 준수한 API만을 의미합니다.
- REST API는 종종 이름만 REST일 뿐, 완전한 RESTful 원칙을 지키지 않을 수 있습니다. 반면, RESTful API는 클라이언트-서버 구조, 무상태성, 리소스 기반 URI 등 모든 REST 원칙을 따릅니다.
3. REST의 6가지 기본 원칙을 통해 RESTful API와 REST API 비교하기
3.1 클라이언트-서버 구조 (Client-Server Architecture)
- REST API: 클라이언트-서버 구조를 따를 수 있지만, 클라이언트와 서버 간의 역할이 모호할 수 있고, 서버에서 상태 정보를 유지하는 경우가 있습니다.
- RESTful API: 클라이언트와 서버가 명확히 분리되어 있으며, 서버는 클라이언트의 상태를 저장하지 않습니다. 클라이언트는 요청만 보내고, 서버는 필요한 리소스만 제공하여 서로 독립적으로 발전할 수 있습니다.
예시
GET /api/v1/products HTTP/1.1
Host: www.example.com- 클라이언트가 서버에 모든 제품 목록을 요청하면, 서버는 그 데이터를 응답하고 클라이언트는 데이터를 사용합니다. 서버는 클라이언트의 상태를 저장하지 않고, 오직 데이터만 처리합니다.
3.2 무상태성 (Statelessness)
- REST API: 일부 API는 무상태성을 지키지 않고 서버에 세션 데이터를 유지할 수 있습니다.
- RESTful API: 모든 요청이 독립적이어야 하며, 서버는 클라이언트의 상태 정보를 저장하지 않습니다. 각 요청은 필요한 정보를 모두 포함하여 보내야 합니다.(예: 인증 정보)
예시
GET /api/v1/products HTTP/1.1
Host: www.example.com
Authorization: Bearer <token>- 각 요청에서 인증 토큰을 포함시켜야 하며, 서버는 이전 요청을 기억하지 않습니다.
3.3 리소스 기반 URI (Resource-Based URIs)
- REST API: URI 설계가 리소스 중심이 아닐 수 있으며, 종종 동사로 설계된 경우가 많습니다. 예를 들어,
GET /getUserInfo와 같은 형태로 사용될 수 있습니다. - RESTful API: 리소스를 명사로 표현하며, URI는 리소스에 접근하는 방식을 명확히 나타냅니다.
예시
GET /api/v1/users/123 # 특정 사용자 리소스 조회
POST /api/v1/users # 새로운 사용자 추가- URI는 리소스 자체를 나타내며, HTTP 메서드를 통해 동작을 정의합니다.
3.4 HTTP 메서드 활용 (Use of HTTP Methods)
- REST API: 모든 HTTP 메서드를 RESTful하지 않게 사용하는 경우가 있습니다. 예를 들어, 데이터 조회나 수정에 관계없이 모든 요청이
POST메서드를 사용하는 API가 있을 수 있습니다. - RESTful API: HTTP 메서드를 목적에 맞게 사용합니다. 데이터 조회는
GET, 리소스 추가는POST, 수정은PUT, 삭제는DELETE와 같이 사용합니다.
예시
GET /api/v1/products # 제품 목록 조회
POST /api/v1/products # 새로운 제품 추가
PUT /api/v1/products/1 # 제품 정보 수정
DELETE /api/v1/products/1 # 제품 삭제- 각 메서드는 그에 맞는 작업을 처리하도록 구분되어 있습니다.
3.5 표현 계층 (Layered System)
- REST API: 클라이언트와 서버 사이에 중간 계층을 사용할 수 있지만, RESTful하지 않게 중간 계층이 클라이언트와 서버의 동작을 방해할 수 있습니다.
- RESTful API: 여러 계층이 존재할 수 있으며, 각 계층은 독립적으로 동작합니다. 클라이언트는 중간에 프록시 서버나 로드 밸런서 등의 계층이 있더라도 이를 인지할 필요가 없습니다.
3.6 캐시 가능성 (Cacheability)
- REST API: 서버가 캐싱 가능성을 명시하지 않거나 잘못된 캐시 처리 정책을 사용할 수 있습니다.
- RESTful API: 서버가 응답에 캐싱 가능 여부를 명시해주면, 클라이언트는 데이터를 캐시하고 성능을 최적화할 수 있습니다.
예시
GET /api/v1/products HTTP/1.1
Cache-Control: max-age=3600 # 1시간 동안 캐시 가능- 서버는 응답에 캐싱 정보를 포함시켜 클라이언트가 데이터를 캐시할 수 있게 합니다.
4. REST API와 RESTful API 비교 요약
| 구분 | REST API | RESTful API |
|---|---|---|
| 무상태성 | 보장하지 않을 수 있음 | 반드시 무상태성 유지 |
| 리소스 기반 URI | 리소스 대신 동사나 작업 기반 URL 사용 | 리소스 중심의 명사형 URI 사용 |
| HTTP 메서드 사용 | HTTP 메서드의 의미가 모호할 수 있음 | 각 HTTP 메서드를 명확한 목적에 맞게 사용 |
| 캐시 가능성 | 명확하지 않거나 사용하지 않을 수 있음 | 클라이언트가 데이터를 캐시할 수 있도록 명시함 |
| 표현 계층 | 계층 간의 역할이 명확하지 않을 수 있음 | 계층 구조를 명확히 유지하며 동작을 독립적으로 처리 |
| 확장성 | 종종 제한적일 수 있음 | 확장성과 유연성을 보장 |
5. 결론
- REST API는 단순히 REST 아키텍처를 사용한 API를 의미하며, 반드시 RESTful한 원칙을 모두 따르지 않을 수 있습니다.
- RESTful API는 REST의 6가지 원칙을 모두 준수하는 API로, 더 명확하고 표준화된 설계를 따릅니다.
RESTful API는 클라이언트와 서버 간의 통신을 명확하고 효율적으로 처리하며, 무상태성을 통해 서버와 클라이언트가 독립적으로 발전할 수 있게 해줍니다. 또한, HTTP 메서드를 목적에 맞게 사용하고, 캐싱과 같은 성능 최적화 기능도 내장되어 있어 확장성과 유지보수성이 뛰어납니다.
REST API와 RESTful API는 유사해 보이지만, RESTful API는 더 엄격하고 규칙적인 설계를 통해 보다 효율적이고 유지보수가 쉬운 시스템을 만듭니다. RESTful API를 구현할 때는 이 원칙들을 모두 준수하는 것이 중요합니다.
