RESTful API (OPEN API)

RESTful API는 REST(Representational State Transfer) 원칙을 따르는 API(Application Programming Interface)를 의미합니다. REST는 HTTP 프로토콜을 기반으로 클라이언트와 서버 간에 데이터를 주고받기 위한 아키텍처 스타일입니다. RESTful API는 HTTP 메서드(GET, POST, PUT, DELETE 등)를 활용하여 서버의 리소스(데이터)에 접근하고 조작할 수 있는 방법을 제공합니다.

1. REST란?

REST는 로이 필딩(Roy Fielding)이 2000년에 제안한 아키텍처 스타일로, HTTP와 같은 기존 웹 표준을 기반으로 클라이언트와 서버 간의 통신을 단순화하고 효율적으로 만들기 위해 고안되었습니다.

REST의 핵심 개념은 리소스(Resource)입니다. 여기서 리소스는 서버에 존재하는 데이터나 정보를 말하며, 각 리소스는 고유한 URI(Uniform Resource Identifier)를 통해 식별됩니다. RESTful API는 이러한 리소스에 대해 CRUD(Create, Read, Update, Delete) 작업을 HTTP 메서드를 통해 수행할 수 있도록 합니다.

2. REST의 주요 원칙

RESTful API는 다음의 주요 원칙을 따릅니다:

1. 클라이언트-서버 구조 (Client-Server Architecture):
   • 클라이언트는 서버의 리소스를 요청하고, 서버는 클라이언트의 요청에 대해 응답합니다.
   • 클라이언트는 리소스의 표현(Representation)을 요청하고, 서버는 해당 리소스를 JSON, XML, HTML 등의 형식으로 응답합니다.
2. 무상태 (Stateless):
   • 서버는 클라이언트의 이전 요청 상태를 저장하지 않습니다. 즉, 각 요청은 독립적이며, 요청마다 필요한 모든 정보를 담고 있어야 합니다.
   • 클라이언트의 상태를 서버가 기억하지 않기 때문에, 서버는 더 단순해지고 확장성이 좋아집니다.
3. 캐시 가능 (Cacheable):
   • 응답 데이터는 캐시될 수 있으며, 서버는 응답 데이터가 캐시 가능한지 여부를 HTTP 응답 헤더에 명시할 수 있습니다. 이를 통해 성능을 향상시키고, 불필요한 중복 요청을 줄일 수 있습니다.
4. 계층화 시스템 (Layered System):
   • 클라이언트는 서버와 직접 통신하거나, 중간에 프록시나 로드 밸런서와 같은 중개 계층을 통해서도 통신할 수 있습니다.
   • 이를 통해 보안이나 로드 밸런싱을 위한 계층을 도입할 수 있습니다.
5. 인터페이스의 일관성 (Uniform Interface):
   • RESTful API는 일관된 인터페이스를 제공해야 합니다. 이를 통해 클라이언트는 다양한 리소스에 동일한 방식으로 접근할 수 있습니다.
   • URI를 통해 리소스를 식별하고, HTTP 메서드(GET, POST, PUT, DELETE 등)를 통해 작업을 수행합니다.
6. 리소스 기반의 URI:
   • REST는 각 리소스를 고유한 URI로 식별합니다.
   • 예를 들어, /users는 모든 사용자를 의미하며, /users/1은 특정 사용자를 나타냅니다.

3. RESTful API의 HTTP 메서드

RESTful API는 HTTP 메서드를 사용하여 리소스에 대한 CRUD 작업을 수행합니다.

HTTP 메서드	동작	설명
GET	조회 (Read)	서버로부터 리소스를 조회합니다. 데이터만 조회하고 수정하지 않습니다.
POST	생성 (Create)	서버에 새로운 리소스를 생성합니다. 주로 새로운 데이터를 추가할 때 사용됩니다.
PUT	수정 (Update)	서버에 존재하는 리소스를 수정합니다. 리소스 전체를 갱신할 때 사용됩니다.
PATCH	부분 수정 (Partial Update)	리소스의 일부를 수정할 때 사용됩니다.
DELETE	삭제 (Delete)	서버에서 리소스를 삭제합니다.

예시:

• GET /users: 모든 사용자의 정보를 가져옵니다.
• GET /users/1: 특정 ID(1)를 가진 사용자의 정보를 가져옵니다.
• POST /users: 새로운 사용자 정보를 서버에 추가합니다.
• PUT /users/1: 특정 사용자의 정보를 전체 업데이트합니다.
• PATCH /users/1: 특정 사용자의 일부 정보를 업데이트합니다.
• DELETE /users/1: 특정 사용자의 정보를 삭제합니다.

4. RESTful API 설계 예시

리소스 구조 예시:

• /users: 모든 사용자 정보를 관리하는 리소스.
• /users/1: 특정 사용자(ID가 1인 사용자)의 정보.
• /products: 모든 제품 정보를 관리하는 리소스.
• /products/42: 특정 제품(ID가 42인 제품)의 정보.

예시 API 설계:

• GET /users: 모든 사용자 정보를 조회.
• POST /users: 새로운 사용자 추가.
• GET /users/1: ID가 1인 사용자의 정보 조회.
• PUT /users/1: ID가 1인 사용자의 정보 전체 수정.
• DELETE /users/1: ID가 1인 사용자 삭제.

5. RESTful API의 응답 형식

RESTful API는 주로 JSON 형식으로 데이터를 주고받습니다. 이는 경량 데이터 형식으로, 웹 애플리케이션에서 쉽게 파싱할 수 있습니다.

JSON 응답 예시:

{
  "id": 1,
  "username": "taehun",
  "email": "taehun@example.com"
}

RESTful API는 JSON 외에도 XML, HTML 등 다른 포맷으로도 데이터를 응답할 수 있으며, 클라이언트는 Accept 헤더를 통해 요청 데이터 형식을 지정할 수 있습니다.

6. RESTful API의 장점

1. HTTP 표준 기반:
   • REST는 HTTP 프로토콜의 표준을 그대로 사용하므로, 이미 널리 사용되는 HTTP 메서드(GET, POST, PUT, DELETE)를 그대로 활용할 수 있습니다.
2. 유연성과 확장성:
   • RESTful API는 클라이언트와 서버가 독립적으로 발전할 수 있도록 설계되었습니다. 클라이언트와 서버는 서로의 변경 사항에 영향을 받지 않으며, REST API 자체가 독립적으로 유지됩니다.
3. 캐싱 기능:
   • HTTP의 캐싱 메커니즘을 활용하여 요청된 리소스를 캐시하고, 서버 부하를 줄일 수 있습니다.
4. 간결하고 일관된 인터페이스:
   • RESTful API는 모든 리소스에 대해 일관된 인터페이스를 제공하므로, 클라이언트는 어떤 리소스에 접근하든 동일한 방식으로 요청하고 응답을 받을 수 있습니다.

7. RESTful API의 단점

1. Overhead:
   • HTTP를 통해 모든 요청을 전송하기 때문에 헤더 정보가 항상 포함되며, 이는 데이터 전송량을 늘릴 수 있습니다.
2. 복잡한 트랜잭션 관리:
   • REST는 무상태성을 지향하기 때문에 복잡한 트랜잭션 관리가 어렵습니다. 여러 단계의 트랜잭션이 필요한 작업을 처리하는 데는 적합하지 않을 수 있습니다.

---

결론:

RESTful API는 HTTP 프로토콜을 기반으로 리소스를 주고받는 웹 서비스를 설계하는 아키텍처 스타일입니다. HTTP 메서드(GET, POST, PUT, DELETE 등)를 통해 서버의 리소스에 접근하고 조작할 수 있으며, 무상태성을 유지하면서도 효율적이고 확장성 있는 API 설계를 지원합니다. RESTful API는 웹 애플리케이션뿐만 아니라 모바일 앱, 마이크로서비스 등 다양한 시스템에서 널리 사용됩니다.