[아키텍처] REST 아키텍처와 RESTful API에 대한 이해

 

개요

RESTful API는 REST 아키텍처 스타일을 만족하는 API입니다.

💡 참고
API는 Application Programming Interface의 약자로 서로 다른 어플리케이션의 상호 통신을 위한 인터페이스입니다. 만약 API 에 대한 이해가 부족하다면 IBM 유튜브를 참고하세요.

 

초기 웹 아키텍처의 문제

초기 웹 아키텍처에선 공통 서버-클라이언트 구현 라이브러리 CERN libwww에 의존했습니다. 이후 웹 생태계가 비대하게 성장하면서 이에 따른 새로운 하위 아키텍처에 대한 필요성이 대두되었습니다.

기존 HTTP 프로토콜 및 기존 아키텍처와 공존할 수 있으며, 확장 가능한 아키텍처가 필요했습니다. 

https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

 

REST (Representational State Transfer)

로이 필딩은 REST 아키텍처를 제시했습니다.

REST는 분산 하이퍼미디어 시스템 아키텍처입니다. 로이 필딩은 REST 아키텍처를 만족하는 성질 6가지를 소개했습니다.

• Uniform Interface : 상호작용 효율성을 위한 인터페이스
• Client-Server : 클라이언트, 서버의 독립적 진화 가능
• Stateless : 요청들은 서로 독립적 (각 요청엔 필요한 모든 정보가 있어야 합니다.)
• Cacheable : 캐시 가능 유무 명시
• Layered System : 레이어 너머를 알지 못해야 함 (예: 프록시 서버)
• Code On Demand (옵션) : 소프트웨어 코드 전달 가능 (예: 자바스크립트)

 

Uniform Interface

Uniform Interface를 만족하기 위한 4가지 하위 조건이 있습니다.

• Identification of resources : 각 리소스를 고유하게 식별
• Manipulation of resources through representations : 각 리소스 표현은 통일
• Self-descriptive messages : 각 리소스 표현은 메시지를 처리하는 방법에 대해 안내해야 함.
• Hypermedia As The Engine Of Application State (HATEOAS) : 리소스 표현에서 상태 전이에 대한 방법을 하이퍼링크로 표현.

 

굉장히 추상적이죠?

Identification of resources와 Manipulation of resources through representations를 만족하는 예시는 다른 블로그 글을 참고해 주세요.

Self-descriptive messages와 Hypermedia As The Engine Of Application State (HATEOAS)를 만족하는 리소스 표현 예시를 한번 보겠습니다. 리소스 표현 예시는 마이크로소프트 블로그에서 가져왔습니다.

💡참고
Uniform Interface의 조건들을 만족하는 리소스 표현 중 하나일 뿐이지, 반드시 이렇게 표현해야 한다는 건 아닙니다.

Currently there are no general-purpose standards that define how to model the HATEOAS principle. The examples shown in this section illustrate one possible, proprietary solution.

{
  "orderID":3,
  "productID":2,
  "quantity":4,
  "orderValue":16.60,
  "links":[
    {
      "rel":"customer",
      "href":"https://adventure-works.com/customers/3",
      "action":"GET",
      "types":["text/xml","application/json"]
    },
    {
      "rel":"customer",
      "href":"https://adventure-works.com/customers/3",
      "action":"PUT",
      "types":["application/x-www-form-urlencoded"]
    },
    {
      "rel":"customer",
      "href":"https://adventure-works.com/customers/3",
      "action":"DELETE",
      "types":[]
    },
    {
      "rel":"self",
      "href":"https://adventure-works.com/orders/3",
      "action":"GET",
      "types":["text/xml","application/json"]
    },
    {
      "rel":"self",
      "href":"https://adventure-works.com/orders/3",
      "action":"PUT",
      "types":["application/x-www-form-urlencoded"]
    },
    {
      "rel":"self",
      "href":"https://adventure-works.com/orders/3",
      "action":"DELETE",
      "types":[]
    }]
}

- Self-descriptive messages 조건 만족 : 위 데이터는 각각의 주문(Order) 리소스에 대한 정보를 포함 (주문의 ID, 제품 ID, 수량, 주문 가치), 이러한 정보를 통해 클라이언트는 메시지를 처리하고 데이터를 이해할 수 있습니다.

 - Hypermedia As The Engine Of Application State (HATEOAS) 조건 만족 : 데이터 내의 "links" 배열은 각 주문 리소스와 관련된 하이퍼미디어 링크를 나타냅니다. 이 링크들은 리소스 간의 관계와 클라이언트가 수행할 수 있는 작업을 설명합니다. ( "customer" 관련 링크는 주문과 관련된 고객 정보를 가져오거나 수정하거나 삭제하는 데 사용될 수 있음을 나타냅니다. 또한 "self" 관련 링크는 현재 주문 리소스 자체를 다시 조회하거나 수정하거나 삭제하는 데 사용될 수 있음을 나타냅니다.)

 

RESTful API

• RESTful API는 REST 아키텍처 스타일을 만족하는 API
• REST 아키텍처 조건은 까다롭고 추상적
• 로이 필딩은 REST 아키텍처를 제시했지, RESTful API 표준에 대해 제시하지 않음

추천드리는 RESTful API 작성법은 마이크로소프트 블로그에서 작성한 RESTful web API design 입니다.

또, 2008년 리처드슨은 REST 아키텍처를 단계적으로 만족하는 API 모델을 4단계(level 0 ~ 3)로 나누어 제시했습니다.

https://martinfowler.com/articles/richardsonMaturityModel.html#level0

대부분의 API는 REST 아키텍처 조건을 모두 만족하지 않습니다. 응답 리소스 표현이 Hypermedia As The Engine Of Application State (HATEOAS) 조건을 만족하는 경우는 별로 보지 못했을 겁니다.

보통 위 도표에서의 level 2 수준 API를 설계합니다.

이때, REST 아키텍처의 일부 조건을 만족하나 모든 조건을 만족하지는 않기에, REST API라고 부르지 RESTful API라고 부르지 않습니다. 그러나 사람에 따라 REST API와 RESTful API를 혼용하여 표현하니... 표현에 너무 신경 쓸 필요는 없습니다. 

 

결론

• REST 아키텍처는 크게 6가지 특징을 가지며 그 중 Uniform Interface 하위 4조건이 있음
• 현실에서 개발자가 완벽한 RESTful API를 설계하는 경우는 별로 없음.
• 일반적으로 REST 아키텍처 스타일과 비슷한 (또는 REST 아키텍처 일부 조건을 만족하는) API 설계
• 모든 조건에 부합하는 완벽한 REST 아키텍처 설계가 정답은 아님.
• 로이 필딩 또한 REST 아키텍처가 유일한 방법이 아니라고 말함.

 

제가 공부하고 이해한 바에 따라 글을 한번 작성해 보았습니다. 올바르지 않은 정보가 있다면 댓글로 언제든지 알려주세요! 

감사합니다.

 

출처

What is a REST API?

Fielding Dissertation: CHAPTER 5: Representational State Transfer (REST)

What is REST - REST API Tutorial

Web API design best practices - Azure Architecture Center

• https://roy.gbiv.com/talks/200709_fielding_rest.pdf