REST
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
1. 개요
REST(Representational State Transfer)는 2000년 로이 필딩에 의해 정의된 네트워크 기반 소프트웨어 아키텍처 스타일이다. 이 아키텍처는 클라이언트-서버 구조, 무상태, 캐시 처리 가능, 인터페이스 일관성, 계층화 시스템, 코드 주문(선택 사항)의 6가지 제약 조건을 갖는다. REST는 웹의 확장성과 성장을 이끄는 핵심 설계 원칙들을 기반으로 하며, 자원(정보 조각)을 URI로 식별하고 표준 HTTP 메서드를 통해 조작한다. REST는 RPC(원격 프로시저 호출)와는 다르게 자원의 다양성을 중시하며, API 분류 모델을 통해 설계 원칙 준수 정도에 따라 분류된다. REST는 블로그, Amazon, eBay, 공공 데이터 포털 등 다양한 분야에서 구현 사례를 찾아볼 수 있으며, 한국에서도 공공 데이터, 금융, 전자상거래 등 다양한 분야에서 활용되고 있다.
로이 필딩은 2000년에 UC 어바인에서 "Architectural Styles and the Design of Network-based Software Architectures"라는 제목의 박사 학위 논문에서 REST를 정의하였다.[19] 필딩은 1996년부터 1999년까지 HTTP 1.0의 기존 디자인을 개선한 HTTP 1.1을 개발하면서 REST 아키텍처 스타일을 함께 개발했다.[20]
''표현 상태 전송''(representational state transfer)이라는 용어는 2000년 컴퓨터 과학자 로이 필딩이 그의 박사 학위 논문에서 소개하고 정의했다. 이는 서버가 리소스의 표현(HTML, XML, 또는 JSON 문서)으로 응답하고, 해당 리소스에는 시스템의 상태를 변경하기 위해 따라갈 수 있는 하이퍼미디어 링크가 포함되어 있음을 의미한다. 이러한 요청은 차례로 리소스의 표현을 받게 되며, 계속해서 반복된다.
2. 역사
웹은 1993~1994년에 일반적인 사용을 위한 웹사이트가 등장하면서 일상적인 사용에 들어서기 시작했다.[3] 당시 웹 아키텍처에 대한 설명은 단편적이었으며, 업계에서는 웹 인터페이스 프로토콜에 대한 표준 합의에 대한 요구가 있었다.[4] 프록시를 지원하기 위해 여러 실험적 확장 기능이 통신 프로토콜(HTTP)에 추가되었고, 더 많은 확장 기능이 제안되었지만, 이러한 변경의 영향을 평가할 수 있는 공식적인 웹 아키텍처가 필요했다.[4]
W3C와 IETF 작업 그룹은 웹의 세 가지 주요 표준인 URI, HTTP, HTML에 대한 공식적인 설명을 작성하는 작업을 함께 시작했다. 필딩은 이러한 표준을 만드는 데 참여했으며, 이후 6년 동안 REST 아키텍처 스타일을 만들고 웹의 프로토콜 표준에 대한 제약 조건을 테스트했으며, 이를 아키텍처 개선을 정의하고 아키텍처 불일치를 식별하는 수단으로 사용했다.
REST 아키텍처 스타일을 만들기 위해 필딩은 전 세계적인 네트워크 기반 애플리케이션을 만들 때 적용되는 요구 사항을 식별했는데, 전 세계적인 채택을 가능하게 하기 위한 낮은 진입 장벽의 필요성 등이 포함되었다. 그는 또한 캐싱 및 클라이언트-서버 기능과 같이 다른 스타일과 공유되는 기능과 리소스 개념과 같이 REST 고유의 기능을 식별하면서 네트워크 기반 애플리케이션에 대한 많은 기존 아키텍처 스타일을 조사했다.
필딩은 현재 구현의 기존 아키텍처를 분류하고 웹의 동작 및 성능 요구 사항에 핵심적으로 고려해야 할 측면을 식별하려고 했다.
웹의 구현은 REST 아키텍처 스타일의 모든 제약 조건을 준수하지 않는다. 무지하거나 간과하여 불일치가 발생할 수 있지만, REST 아키텍처 스타일이 존재한다는 것은 불일치가 표준화되기 전에 식별될 수 있음을 의미한다. 예를 들어 필딩은 세션 정보를 URI에 포함하는 것은 공유 캐싱 및 서버 확장성에 부정적인 영향을 미칠 수 있는 REST의 제약 조건 위반으로 식별했다. HTTP 쿠키 또한 브라우저의 애플리케이션 상태와 동기화되지 않아 신뢰할 수 없고, 개인 정보 보호 및 보안에 대한 문제가 될 수 있는 불투명한 데이터를 포함하기 때문에 REST 제약 조건을 위반했다.[4]
2. 1. REST 개발 배경 (한국의 상황)
3. 원리
중요한 결과는 알아야 할 유일한 식별자는 처음에 요청된 리소스의 식별자이며, 다른 모든 식별자는 발견될 것이라는 점이다. 이는 이러한 식별자가 클라이언트에게 미리 알릴 필요 없이 변경될 수 있으며, 클라이언트와 서버 간에 느슨한 결합만 존재할 수 있음을 의미한다.
만약에 클라이언트가 관련된 리소스에 접근하기를 원한다면, 리턴되는 지시자에서 구별될 수 있어야 한다. 충분한 콘텍스트 속에서의 URI를 제공해주는 하이퍼텍스트 링크의 예를 들 수 있겠다.
REST에서 중요한 개념은 "자원"(정보 조각)이다. 개별 자원은 글로벌 식별자(URI)로 참조할 수 있다. 자원에 대한 조작은 다음과 같이 수행된다.
하지만 실제로는 이러한 자원 조작이 논의의 대상이 되고 있다. 일부 사람들은 "자원"과 "표현"을 구별하는 것이 관념적이라는 의견이 있다. 다만 RDF 커뮤니티에서는 자원과 표현의 구별이 일반적으로 이루어지고 있다.
다양한 "커넥터"(클라이언트, 서버, 캐시, 터널 등)가 요청을 중개할 수 있다. 단, 커넥터는 과거 요청을 참조하지 않고 중개할 수 있어야 한다.
: 이는 REST의 원칙을 구성하는 "계층화"라고 불리는 제약이다. 계층화는 정보 아키텍처나 네트워크 아키텍처의 다른 많은 부분에서도 볼 수 있는 일반적인 설계 원칙이기도 하다.
이렇게 함으로써 REST 애플리케이션은 다음 두 가지 정보를 인식하여 자원을 다룰 수 있다.
애플리케이션과 실제 정보를 가진 서버 사이에 있는 다른 것에 대해 의식할 필요는 없다. 즉 애플리케이션은 캐시나 프록시, 게이트웨이, 방화벽, 터널 등의 유무를 의식할 필요가 없다.
단, 애플리케이션은 반환된 정보(표현)의 형식을 이해할 수 있어야 한다. 그 형식은 많은 경우 어떤 HTML이나 XML 문서이지만, 경우에 따라 이미지나 기타 콘텐츠일 수도 있다.
3. 1. REST 아키텍처의 6가지 제약 조건
REST 아키텍처 스타일은 성능, 확장성, 단순성, 수정 용이성, 가시성, 이식성 및 신뢰성과 같은 바람직한 비기능적 속성을 얻기 위해 여섯 가지 지침 제약 조건을 정의한다.[1] 이러한 제약 조건을 준수하는 한 개별 컴포넌트는 자유롭게 구현할 수 있다.
REST를 지지하는 사람들은 웹의 확장성과 성장은 무상태 클라이언트/서버 프로토콜, 모든 정보(리소스)에 적용할 수 있는 "잘 정의된 조작" 세트, 리소스를 고유하게 식별하는 "범용 구문", 애플리케이션의 정보와 상태 전이를 모두 처리할 수 있는 "하이퍼미디어 사용"과 같은 몇 가지 핵심 설계 원칙의 결과라고 주장한다.
3. 2. REST의 주요 목표
REST는 네트워크 기반 애플리케이션, 특히 클라이언트-서버 애플리케이션을 위해 설계되었으며, 인터넷 규모의 사용을 목표로 한다. 사용자 에이전트(클라이언트)와 원 서버 간의 느슨한 결합은 대규모 채택을 용이하게 한다.
클라이언트와 서버의 강력한 분리, 균일한 주소 지정 프로토콜을 사용하는 텍스트 기반 정보 전송은 웹의 요구 사항인 확장성, 무정부적 확장성, 구성 요소의 독립적인 배포, 대용량 데이터 전송, 콘텐츠 리더, 콘텐츠 작성자 및 개발자를 위한 낮은 진입 장벽을 충족하는 기반을 제공한다.
REST 아키텍처 스타일의 제약 조건은 구성 요소 간의 상호 작용 성능, 확장성, 균일한 인터페이스의 단순성, 구성 요소의 수정 가능성, 서비스 에이전트에 의한 구성 요소 간 통신의 가시성, 데이터와 함께 프로그램 코드를 이동하여 구성 요소의 이식성, 그리고 시스템 수준의 장애에 대한 저항성인 신뢰성에 영향을 미친다.[6]
REST의 주요 설계 원칙은 다음과 같다.
4. REST와 RPC
REST는 원격 프로시저 호출(RPC)와 다른 설계 접근 방식을 사용한다. RPC는 프로토콜 작업(동사)의 다양성을 중시하는 반면, REST는 자원(명사)의 다양성을 중시한다.
RPC 애플리케이션이 정의하는 작업의 예시는 다음과 같다.
- getUser()*
- addUser()*
- removeUser()*
- updateUser()*
- getLocation()*
- addLocation()*
- removeLocation()*
- updateLocation()*
- listUsers()*
- listLocations()*
- findLocation()*
- findUser()*
반면 REST 애플리케이션이 정의하는 리소스 유형의 예시는 다음과 같다.
- User {}*
- Location {}*
각각의 리소스는 `http://www.example.org/locations/us/ny/new_york_city`와 같은 고유한 URI를 가지며, 클라이언트는 표준 HTTP 메서드를 사용하여 이 리소스를 다룬다. 예를 들어, HTTP GET을 사용하여 리소스의 복사본을 다운로드하고, 업데이트된 복사본을 HTTP PUT으로 업로드하며, HTTP DELETE를 사용하여 해당 리소스의 모든 표현을 삭제한다. 각각의 리소스가 고유한 URI를 가지므로 캐싱, 복사, 북마크가 쉽다. HTTP POST는 일반적으로 구매 주문을 하거나 컬렉션에 정보를 추가하는 등 부작용이 있는 액션에 사용된다.
HTTP 메서드가 리소스를 발견하기 위한 표준 메서드를 모두 제공하지는 않기 때문에, RPC의 `list*()`나 `find*()`에 해당하는 HTTP LIST나 FIND와 같은 메서드는 HTTP에서 규정하지 않는다.
REST는 컬렉션이나 검색 결과의 집합을 다른 유형의 "리소스"로 취급하여 이 문제에 대처한다. 애플리케이션 설계자는 리소스의 검색이나 목록 취득을 위해 상황에 따라 해당 URI나 URI 패턴을 알고 있어야 한다. 예를 들어, `http://www.example.org/locations/us/ny/`라는 URI에 대한 HTTP GET 요청은 뉴욕 각지의 정보를 가진 XML 파일에 대한 링크 목록을 반환하고, `http://www.example.org/users?surname=Michaels`라는 URI에 대한 HTTP GET 요청은 "Michaels" 성을 가진 모든 사용자에 대한 링크 목록을 반환한다.
REST는 이러한 액션을 수행하는 방법에 대한 몇 가지 단서를 제공하며, 이는 "애플리케이션 상태 엔진으로서의 하이퍼미디어"라는 제약에서 얻어진다. 이 제약에서 유도되는 실현 수단 중 하나는 파라미터가 있는 요청에 대해 HTML 폼과 같은 폼 언어를 사용하는 것이다.
A9.com의 OpenSearch 이니셔티브는 REST를 사용한 검색의 표준화 작업을 진행하고 있다. 구체적으로는, RDF, XTM, Atom, RSS (방언 포함), 링크를 다루기 위한 XLink와 결합된 간단한 구조의 XML (Plain Old XML; POX)을 포함하는 일반적인 형식을 REST 시스템에서 사용함으로써, 정보를 발견하기 위한 규격의 제정이다.
5. RESTful API 분류 모델
리처드슨 성숙도 모델이나 HTTP 기반 API 분류[11], W S3 성숙도 모델[12] 등 REST API의 설계 원칙 준수 정도에 따라 REST API를 분류하는 데 도움이 되는 여러 모델이 개발되었다.
6. 공개된 구현 사례
REST는 광범위하게 정의되어 있어, 웹상에 존재하는 많은 수의 RESTful 애플리케이션(HTTP GET 요청으로 접근 가능한 모든 것)을 포함할 수 있다. 좁은 의미로 보더라도, REST는 웹 곳곳에서 찾아볼 수 있다.
- 블로그에서는 RSS 2.0, RSS 1.0, Atom 형식의 XML 파일을 통해 다른 리소스에 대한 링크 목록을 제공한다.
- Amazon.com은 [http://www.amazon.com/gp/aws/landing.html 개발자 인터페이스]를 REST 버전과 SOAP 버전으로 제공하며, REST 버전이 트래픽의 대부분을 차지한다.
- eBay는 REST [http://developer.ebay.com/rest/ 개발자 인터페이스]를 제공한다.
- 캐나다 정부의 [http://www.seniors.gc.ca/index.jsp "Seniors Canada On-line"] 프로젝트는 REST 인터페이스를 제공한다([http://www.megginson.com/blogs/quoderat/archives/2005/03/09/public-rest-application-seniors-canada-online/ 설명]).
- Bloglines는 REST [http://bloglines.com/services/ 개발자 인터페이스]를 제공한다.
- Yahoo!는 REST [http://developer.yahoo.com 개발자 인터페이스]를 제공한다.
- Openomy는 REST 기반 온라인 파일 스토리지 시스템이다.
- Ruby on Rails의 URL 라우팅은 MVC디자인 패턴을 사용하여 RESTful 애플리케이션 설계를 지원한다.
- Zope의 객체 발행 시스템.
- ASP.NET의 ASP.NET WebAPI는 RESTful API를 일반적인 RPC 메서드 구현과 거의 동일한 간편함으로 작성할 수 있게 한다. 또한, ASP.NET MVC Framework를 사용하여 기존 MVC 구조를 사용한 구현도 지원한다.
위에 언급된 많은 예시들이 REST의 모든 아키텍처 제약을 따르는 것은 아니지만, REST에서 영감을 받았으며, REST의 대부분의 아키텍처 제약, 특히 통일된 인터페이스 제약의 중요성을 인식하고 있다. 이러한 서비스는 [http://www.markbaker.ca/2002/09/Blog/2005/04/14#2005-04-amazon-next 「우연에 의한 RESTful]이라고 불리기도 한다.
한국의 경우, RESTful API는 다양한 분야에서 활용되고 있다.
공공 데이터 포털: 정부 및 공공기관은 RESTful API를 통해 다양한 공공 데이터를 개방하여 시민과 기업이 활용할 수 있도록 지원하고 있다. 예를 들어, 공공데이터포털에서는 날씨, 교통, 환경 등 다양한 공공 데이터를 RESTful API 형태로 제공한다.
금융 API: 핀테크 산업의 성장과 함께 은행, 증권사 등 금융기관들은 RESTful API를 통해 계좌 정보, 거래 내역, 투자 정보 등을 제공하고 있다. 카카오뱅크, 토스와 같은 핀테크 기업들은 RESTful API를 적극 활용하여 혁신적인 금융 서비스를 제공한다.
전자상거래: 대부분의 온라인 쇼핑몰은 상품 정보, 주문, 결제 등 핵심 기능을 RESTful API로 제공하여 외부 시스템과의 연동을 용이하게 하고 있다. 쿠팡, G마켓 등 대규모 전자상거래 플랫폼은 물론, 네이버 쇼핑과 같은 포털 기반 쇼핑 서비스도 RESTful API를 활용한다.
6. 1. 한국의 RESTful API 활용 사례
한국의 경우, RESTful API는 다양한 분야에서 활용되고 있다.공공 데이터 포털: 정부 및 공공기관은 RESTful API를 통해 다양한 공공 데이터를 개방하여 시민과 기업이 활용할 수 있도록 지원하고 있다. 예를 들어, 공공데이터포털에서는 날씨, 교통, 환경 등 다양한 공공 데이터를 RESTful API 형태로 제공한다.
금융 API: 핀테크 산업의 성장과 함께 은행, 증권사 등 금융기관들은 RESTful API를 통해 계좌 정보, 거래 내역, 투자 정보 등을 제공하고 있다. 카카오뱅크, 토스와 같은 핀테크 기업들은 RESTful API를 적극 활용하여 혁신적인 금융 서비스를 제공한다.
전자상거래: 대부분의 온라인 쇼핑몰은 상품 정보, 주문, 결제 등 핵심 기능을 RESTful API로 제공하여 외부 시스템과의 연동을 용이하게 하고 있다. 쿠팡, G마켓 등 대규모 전자상거래 플랫폼은 물론, 네이버 쇼핑과 같은 포털 기반 쇼핑 서비스도 RESTful API를 활용한다.
7. 비판 및 한계
참조
[1]
학위논문
Architectural Styles and the Design of Network-based Software Architectures
University of California, Irvine
2004-08-17
[2]
웹사이트
REST APIs must be hypertext driven
http://roy.gbiv.com/[...]
roy.gbiv.com
2016-07-06
[3]
서적
Media, Society, World: Social Theory and Digital Media Practice
https://books.google[...]
Polity Press
2021-06-09
[4]
학위논문
Architectural Styles and the Design of Network-based Software Architectures
University of California, Irvine
2023-06-21
[5]
웹사이트
Fielding discussing the definition of the REST term
https://groups.yahoo[...]
groups.yahoo.com
2017-08-08
[6]
학위논문
Architectural Styles and the Design of Network-based Software Architectures
University of California, Irvine
2014-04-12
[7]
서적
SOA with REST: Principles, Patterns & Constraints for Building Enterprise Solutions with REST
Prentice Hall
2012
[8]
서적
RESTful Web Services
https://archive.org/[...]
O'Reilly Media
2007
[9]
웹사이트
What is REST API?
https://www.visual-p[...]
2024-02-24
[10]
웹사이트
REST HATEOAS
http://restfulapi.ne[...]
RESTfulAPI.net
2019-03-10
[11]
웹사이트
Classification of HTTP APIs
http://algermissen.i[...]
2023-01-29
[12]
간행물
A Maturity Model for Semantic RESTful Web APIs
https://www.research[...]
2020-12-14
[13]
웹사이트
REST ‐ 通信用語の基礎知識
https://www.wdic.org[...]
2021-12-18
[14]
웹사이트
REST
https://atmarkit.itm[...]
2021-12-18
[15]
웹사이트
本当にRESTは「4つの原則」？原文に当たって分かった驚きの事実
https://xtech.nikkei[...]
2021-12-18
[16]
웹사이트
REST APIとは何か？をわかりやすく説明するために論文を読んでみた {{!}} 瀬戸内の雲のように
https://www.setouchi[...]
2021-12-18
[17]
서적
Foundations of Modern Networking: SDN, NFV, QoE, IoT, and Cloud
Addison-Wesley Professional
[18]
웹사이트
データサイエンス、AI・開発のためのPython
https://www.coursera[...]
2023-05-24
[19]
학위논문
Architectural Styles and the Design of Network-based Software Architectures
University of California, Irvine
[20]
웹인용
Fielding discusses the development of the REST style
http://tech.groups.y[...]
Tech.groups.yahoo.com
2014-09-14
본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.
문의하기 : help@durumis.com