RESTful API

아트·2024년 9월 13일

Computer Science

목록 보기

7/14

RESTful API에 대한 설명

1. 정의

RESTful API는 Representational State Transfer(REST) 원칙을 따르는 API를 의미하며, 클라이언트와 서버 간의 상호작용을 구조화하는 아키텍처 스타일입니다. REST는 리소스를 표현하고 상태를 전달하는 HTTP 프로토콜을 기반으로 한 웹 서비스를 설계하는 방식입니다.

2. REST 아키텍처

REST 아키텍처는 다음의 주요 원칙을 기반으로 합니다:

클라이언트-서버 구조 (Client-Server Architecture): 클라이언트와 서버는 명확히 분리되어 동작하며, 클라이언트는 사용자 인터페이스를 담당하고 서버는 데이터와 로직을 담당합니다.
상태 비저장성 (Statelessness): 클라이언트의 각 요청은 독립적이며, 서버는 요청 간 상태를 유지하지 않습니다. 모든 요청은 필요한 정보를 포함하여야 하며, 서버는 요청을 처리하고 응답합니다.
캐시 가능성 (Cacheability): 서버의 응답은 캐시될 수 있어야 하며, 이를 통해 클라이언트는 동일한 요청에 대해 서버를 반복적으로 요청하지 않고 성능을 향상시킬 수 있습니다.
계층화된 시스템 (Layered System): 클라이언트는 서버와 직접 상호작용하는 것이 아니라 중간 계층(예: 프록시, 로드 밸런서)을 통해 상호작용할 수 있으며, 이러한 계층화된 구조로 복잡한 시스템을 구축할 수 있습니다.
인터페이스 일관성 (Uniform Interface): 리소스와 상호작용하는 방식이 일관적이어야 하며, 모든 리소스는 고유한 URI로 식별됩니다.

3. REST의 탄생 배경

REST는 2000년에 로이 필딩(Roy Fielding)이 그의 박사 논문에서 제시한 개념으로, 당시에는 웹 서비스가 복잡하고 비효율적이라는 문제가 있었습니다. SOAP와 같은 기존 웹 서비스는 구조적으로 복잡하고 확장성이 부족했기 때문에, 이러한 문제를 해결하기 위해 REST가 탄생했습니다. REST는 기존의 HTTP 프로토콜을 최대한 활용하여 단순하고 확장 가능한 아키텍처를 제공함으로써 더 나은 웹 서비스 설계를 가능하게 했습니다.

4. 발달 과정

REST는 점차 웹 API 설계의 표준으로 자리 잡았으며, 특히 웹과 모바일 애플리케이션이 급격히 성장함에 따라 RESTful API가 널리 사용되었습니다. 클라우드 컴퓨팅과 마이크로서비스 아키텍처의 등장으로 인해 REST는 대규모 시스템에서 데이터 교환 및 통합의 핵심 역할을 하게 되었습니다.

5. REST의 문제점

RESTful API는 많은 장점을 가지고 있지만, 몇 가지 문제점도 존재합니다:

오버헤드: HTTP 헤더와 상태 코드, URI 등이 요청 및 응답에서 반복적으로 사용되면서 데이터 전송량이 증가할 수 있습니다.
복잡한 엔드포인트 관리: 대규모 API에서는 엔드포인트가 복잡해지기 쉽고, 이를 일관성 있게 유지하는 것이 어려울 수 있습니다.
실시간 통신의 한계: REST는 기본적으로 요청-응답 모델에 기반하고 있어 실시간 양방향 통신에는 적합하지 않습니다. 이 때문에 웹소켓이나 gRPC 같은 대체 프로토콜이 실시간 통신에 사용되기도 합니다.

6. REST의 개선점

GraphQL: 클라이언트가 필요한 데이터만 요청할 수 있도록 설계된 GraphQL은 REST의 단점을 보완하는 대안으로 떠오르고 있습니다.
HTTP/2: HTTP/2의 멀티플렉싱 기능은 REST API의 성능을 향상시킬 수 있습니다. 이를 통해 여러 요청을 동시에 처리할 수 있습니다.
서버 푸시: 실시간 통신의 한계를 극복하기 위해 서버가 클라이언트에게 직접 데이터를 푸시하는 기능을 지원하는 HTTP/2 기반의 방식도 고려될 수 있습니다.

7. 실제 사용 예시

RESTful API는 다양한 곳에서 사용됩니다:

SNS: Facebook, Twitter, Instagram 등의 소셜 네트워크 서비스는 RESTful API를 통해 사용자 데이터 및 게시물을 주고받습니다.
이커머스: 아마존, 이베이 등은 상품 목록, 주문 처리, 결제 시스템을 RESTful API로 관리합니다.
클라우드 서비스: AWS, Google Cloud, Azure 등의 클라우드 플랫폼은 RESTful API를 제공하여 인프라를 프로그래밍 방식으로 제어할 수 있게 합니다.

8. RESTful API 제작하는 법

RESTful API를 제작하는 과정은 간단합니다:

리소스 설계: API가 다룰 리소스를 결정합니다. 예를 들어, '사용자', '게시물', '댓글' 등의 리소스를 생각할 수 있습니다.
URI 설계: 각 리소스는 고유한 URI로 식별되어야 합니다. URI는 명확하고 일관되게 설계되어야 하며, 일반적으로 소문자와 하이픈(-)을 사용합니다.
- 예시: /users, /posts, /comments
HTTP 메서드 정의: 각 리소스에 대해 적절한 HTTP 메서드를 사용합니다.
- GET /users: 모든 사용자 정보 조회
- POST /users: 새 사용자 생성
- PUT /users/{id}: 특정 사용자 정보 업데이트
- DELETE /users/{id}: 특정 사용자 삭제
상태 코드 사용: 각 요청의 처리 결과를 알리기 위해 HTTP 상태 코드를 반환합니다.
- 200: 성공
- 201: 리소스 생성 성공
- 400: 잘못된 요청
- 404: 리소스 찾을 수 없음
- 500: 서버 오류

9. URL 표준 규칙 및 예시

RESTful API 설계 시 URI는 리소스를 명확하게 나타내고, 일관성을 유지해야 합니다. 주요 규칙은 다음과 같습니다:

소문자 사용: URI는 소문자로 작성합니다. 대문자는 혼동을 일으킬 수 있습니다.
- 잘못된 예시: /Users/123
- 올바른 예시: /users/123
하이픈 사용: URI 내 단어 구분은 하이픈을 사용합니다.
- 잘못된 예시: /user_profile
- 올바른 예시: /user-profile
명사 사용: 리소스를 나타내는 URI는 명사로 작성하며, 동사는 HTTP 메서드로 표현합니다.
- 잘못된 예시: /getUser
- 올바른 예시: /users
복수형 사용: 리소스를 나타내는 URI는 복수형 명사를 사용합니다.
- 잘못된 예시: /user
- 올바른 예시: /users
HTTP 메서드와 일관성: 적절한 HTTP 메서드를 사용하여 URI의 의미를 명확히 합니다.
- GET /posts: 모든 게시물 조회
- POST /posts: 새 게시물 생성
- PUT /posts/{id}: 특정 게시물 수정
- DELETE /posts/{id}: 특정 게시물 삭제

10. RESTful API 예시

사용자 관련 API 예시

GET /users
응답:
[
  {
    "id": 1,
    "name": "John Doe",
    "email": "john@example.com"
  },
  {
    "id": 2,
    "name": "Jane Smith",
    "email": "jane@example.com"
  }
]

POST /users
요청 본문:
{
  "name": "Alice",
  "email": "alice@example.com"
}
응답:
{
  "id": 3,
  "name": "Alice",
  "email": "alice@example.com"
}

PUT /users/1
요청 본문:
{
  "name": "John Doe Updated",
  "email": "johnupdated@example.com"
}
응답:
{
  "id": 1,
  "name": "John Doe Updated",
  "email": "johnupdated@example.com"
}

DELETE /users/1
응답: 204 No Content