Notice
Recent Posts
Recent Comments
Link
«   2024/09   »
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30
Tags
more
Archives
Today
Total
관리 메뉴

Nonamed Develog

[TIL][240903] RESTful API 본문

WHAT I LEARN/TIL

[TIL][240903] RESTful API

노네임드개발자 2024. 9. 3. 19:19

1. REST의 정의

REST(Representational State Transfer)는 2000년 로이 필딩(Roy Fielding)의 논문에서 소개된 웹 아키텍처 스타일이다. REST는 웹의 기존 프로토콜인 HTTP를 기반으로 하여 시스템 간의 상호작용을 단순하고 확장 가능하게 만드는 것을 목표로 한다. REST는 자원을 기반으로 클라이언트와 서버 간에 상태 정보를 교환하는 방식으로, 이를 통해 웹 애플리케이션 간의 통신을 효율적으로 관리할 수 있다.

2. REST의 주요 원칙

REST의 아키텍처는 다음과 같은 6가지 주요 원칙에 기반한다:

  1. 클라이언트-서버 구조 (Client-Server Architecture):
    클라이언트와 서버는 서로 독립적으로 동작해야 한다. 클라이언트는 사용자 인터페이스를 담당하고, 서버는 비즈니스 로직과 데이터 저장소를 담당한다. 이 분리는 클라이언트와 서버의 독립적인 발전을 가능하게 한다.

  2. 무상태성 (Statelessness):
    모든 요청은 서로 독립적이어야 하며, 서버는 클라이언트의 상태를 저장하지 않는다. 즉, 클라이언트의 모든 요청에는 필요한 모든 정보가 포함되어야 하며, 서버는 요청을 통해 받은 정보만을 이용해 처리한다. 이를 통해 서버 확장성이 개선되고, 요청 처리의 일관성이 유지된다.

  3. 캐시 가능 (Cacheable):
    서버의 응답은 명시적으로 캐시 가능해야 한다. 즉, 응답에 따라 클라이언트가 데이터를 캐시할 수 있는지 여부를 결정할 수 있는 정보가 포함되어야 한다. 이를 통해 클라이언트의 성능을 최적화할 수 있다.

  4. 계층화 시스템 (Layered System):
    클라이언트는 중간 서버(프록시, 게이트웨이 등)를 통해 서버와 통신할 수 있다. 이 계층 구조는 보안, 로드 밸런싱, 캐싱 등의 기능을 구현하는 데 유용하다.

  5. 인터페이스 일관성 (Uniform Interface):
    시스템 전반에 걸쳐 일관된 인터페이스가 사용되어야 한다. 이는 REST의 핵심 원칙 중 하나로, 리소스를 식별하고, 리소스에 대한 조작을 일관되게 수행할 수 있도록 보장한다.

  6. 주문형 코드 (Code on Demand, 선택적):
    클라이언트는 서버로부터 실행 가능한 코드를 다운로드하여 실행할 수 있다. 이 원칙은 선택적이며, 주로 클라이언트의 기능 확장을 목적으로 한다.

3. RESTful API란?

RESTful API는 REST 원칙을 준수하는 애플리케이션 프로그래밍 인터페이스(API)이다. RESTful API는 클라이언트와 서버 간의 상호작용을 표준화된 방식으로 처리하며, 웹 애플리케이션에서 자원(Resource)을 관리하는 데 주로 사용된다.

RESTful API는 HTTP 프로토콜의 메서드를 이용하여 자원에 대한 CRUD(Create, Read, Update, Delete) 작업을 수행한다. 각 HTTP 메서드는 특정 작업에 매핑된다:

  • GET: 서버에서 자원을 조회한다. (Read)
  • POST: 서버에 새로운 자원을 생성한다. (Create)
  • PUT: 서버의 기존 자원을 수정한다. (Update)
  • DELETE: 서버에서 자원을 삭제한다. (Delete)

4. RESTful API의 특성

RESTful API는 다음과 같은 특성을 가진다:

  1. 리소스 기반:
    RESTful API는 모든 것을 리소스로 간주하며, 각 리소스는 고유한 URI로 식별된다. 예를 들어, https://api.example.com/users/1은 users 리소스에서 ID가 1인 특정 사용자를 식별한다.

  2. HTTP 메서드 활용:
    HTTP 메서드를 사용하여 자원에 대한 다양한 작업을 수행한다. 이 방법은 직관적이며, 각각의 메서드가 수행하는 작업이 명확하게 정의된다.

  3. 무상태성:
    API 요청은 무상태적이며, 각각의 요청은 독립적으로 처리된다. 클라이언트의 모든 요청은 필요한 모든 정보를 포함하고 있으며, 서버는 이전 요청의 상태를 기억하지 않는다.

  4. 표현 형태:
    서버는 클라이언트의 요청에 따라 다양한 형식(예: JSON, XML)으로 자원의 표현을 반환할 수 있다. 클라이언트는 요청 헤더에 Accept를 지정하여 원하는 표현 형식을 선택할 수 있다.

  5. 캐싱 가능:
    RESTful API의 응답은 캐시될 수 있으며, 이를 통해 클라이언트의 성능을 최적화할 수 있다. 서버는 응답 헤더에 Cache-Control을 포함하여 응답이 캐시 가능한지 여부를 명시한다.

5. RESTful API의 장단점

장점:

  • 확장성: REST의 무상태성과 클라이언트-서버 분리는 시스템 확장성을 높여준다.
  • 유연성: 다양한 클라이언트(웹, 모바일, IoT)에서 사용할 수 있으며, 표준화된 인터페이스 덕분에 이해와 사용이 용이하다.
  • 효율성: 캐싱 및 계층화 시스템을 통해 네트워크 성능을 최적화할 수 있다.

단점:

  • 복잡한 쿼리 처리: 단순한 CRUD 작업에는 적합하지만, 복잡한 트랜잭션 처리나 상태 관리를 필요로 하는 애플리케이션에는 적합하지 않을 수 있다.
  • 버전 관리: API의 버전 관리를 적절히 하지 않으면, 다양한 클라이언트를 지원하는 데 어려움이 있을 수 있다.
  • 보안: HTTP를 기반으로 하므로, HTTPS를 사용하여 보안을 강화해야 한다.