Post

REST API

Posted
By Blake Woo 6 min read

REST API

REST는 Roy Fielding이 2000년 박사논문에서 정립한 웹 아키텍처 스타일이다. REST API(Representational State Transfer Application Programming Interface)의 약자로 REST API라는 별도의 공식 표준이 있는 것은 아니다. 실제 REST API는 IETF가 표준화한 HTTP와 URI 등의 표준을 REST의 제약조건에 맞게 사용하는 방식이다.

1. RESTful API의 6가지 제약

REST API는 알겠는데 RESTful API는 뭘까?
REST한 느낌이 가득한 API 정도로 이해하면 되는데 아래의 6가지 조건을 만족한다면 RESTful API라고 할 수 있다.

1) Client-Server

Client-Server 스타일이어야한다. User Interface에 대한 관심사와 데이터 저장에 대한 관심사를 분리함으로써, Client는 여러 플랫폼에서 이식성을 높일 수 있고 Server는 구성 요소를 단순화하여 확장성을 개선할 수 있다.

2) Stateless

Client와 Server 간의 통신은 Stateless(무상태)여야 한다. 즉, Client의 요청(Request)에 필요한 모든 정보가 요청 자체에 포함되어야 하며, Server는 Client의 Context를 세션 형태로 저장하지 않는다. 이는 Server의 가시성(Visibility), 신뢰성(Reliability), 그리고 확장성(Scalability)을 높여준다.

3) Cache

효율적인 네트워크 리소스 활용을 위해 Cache(캐시) 제약 조건이 추가된다. 응답 데이터에는 해당 데이터가 캐싱 가능한지 여부가 명시되어야 하며, 이를 통해 Client는 동일한 요청에 대해 이전에 저장된 데이터를 재사용함으로써 지연 시간(Latency)을 줄이고 효율성을 높일 수 있다.

4) Uniform Interface

REST의 가장 핵심적인 특징은 구성 요소 간의 Uniform Interface(균일한 인터페이스)이다.

  • Identification of resources (리소스의 식별)
    요청 내에서 개별 리소스가 식별되어야 합니다. 웹에서는 이를 위해 주로 URI를 사용한다.

  • Manipulation of resources through representations (표현을 통한 리소스 조작)
    Client가 리소스의 메타데이터를 포함한 특정 표현(representation)을 보유하고 있다면, 이를 통해 서버의 리소스를 수정하거나 삭제할 수 있는 충분한 정보를 가진 것으로 간주한다.

  • Self-descriptive messages (자기 서술적 메시지)
    각 메시지는 그 자체로 어떻게 처리되어야 하는지 설명할 수 있는 충분한 정보를 포함해야 합니다. 예를 들어, MIME type과 같은 미디어 타입을 통해 데이터의 해석 방법을 전달한다.

  • Hypermedia as the engine of application state (HATEOAS)
    애플리케이션의 상태 변화는 하이퍼미디어(링크 등)를 통해 이루어져야 한다.

5) Layered System

아키텍처는 Layered System(계층화된 시스템)으로 구성될 수 있다. Client는 자신이 직접 연결된 Server와 통신하는지, 혹은 중간 매개체(Intermediary)와 통신하는지 알 수 없도록 설계된다. 이를 통해 프록시나 게이트웨이 같은 중간 구성 요소를 사용하여 보안을 강화하거나 로드 밸런싱을 수행할 수 있다.

6) Code-on-Demand (Optional)

이 제약 조건은 선택 사항으로, Server가 Client에게 실행 가능한 코드(예: Applet, Script)를 전송하여 Client의 기능을 일시적으로 확장할 수 있게 한다. 이는 Client에 미리 구현해야 하는 기능의 수를 줄여 시스템을 단순화할 수 있는 이점을 제공한다.

2. REST API 구조에 근거한 WEB API

1) CRUD

CREATE, READ, UPDATE, DELETE의 약자를 줄여서 CRUD라고 한다. WEB에서는 이러한 CRUD를 이용할 때 아래의 메소드를 사용한다.

  • CREATE : POST
  • READ : GET
  • UPDATE : PUT, PATCH
  • DELETE: DELETE

그리고 여기엔 나와있지 않지만 OPTION이라는 메소드도 있다. 이러한 OPTION 메소드는 해당 서버에 요청가능한 메소드 리스트를 받아온다.

2) URI 설계법

※ 추가 업데이트 예정이다.

참고문헌

  • Fielding, Roy Thomas. “Architectural styles and the design of network-based software architectures.” PhD diss., University of California, Irvine, 2000.
web
web rest api
This post is licensed under CC BY 4.0 by the author.