쉬다

REST
기타 용도는 휴식을 참조하십시오.

REST(Representational state transfer)는 월드 와이드 웹을 위한 아키텍처의 설계와 개발을 안내하기 위해 만들어진 소프트웨어 아키텍처 스타일입니다. REST는 웹과 같은 인터넷 규모의 분산 하이퍼미디어 시스템의 아키텍처가 어떻게 동작해야 하는지에 대한 일련의 제약 조건을 정의합니다.REST 아키텍처 스타일은 통일된 인터페이스, 독립적인 구성 요소 배치, 구성 요소 간 상호 작용의 확장성을 강조하며 캐싱을 촉진하여 사용자가 인식하는 지연 시간을 줄이고 보안을 강화하며 레거시 시스템을 캡슐화하는 계층형 아키텍처를 제공합니다.[1]

REST는 상태 비저장의 신뢰할 수 있는 웹 기반 애플리케이션을 만들기 위해 소프트웨어 산업 전반에 걸쳐 사용되어 왔습니다.REST 제약 조건을 준수하는 애플리케이션은 비공식적으로 RESTful로 표현될 수 있습니다.이 용어는 HTTP 기반 API의 설계와 리소스가 응답하는 "동사"(HTTP 메서드)와 관련하여 널리 알려진 모범 사례와 관련되어 있지만 원래 공식화된 대로 REST와는 거의 관련이 없으며 개념과 상충되는 경우도 많습니다.[2]

원칙

표현적 상태 전이라는 용어는 2000년 컴퓨터 과학자 로이 필딩이 박사학위 논문에서 소개하고 정의했습니다.즉, 서버가 리소스 표현으로 응답하고(오늘날 대부분 HTML, XML 또는 JSON 문서가 됨), 해당 리소스에는 시스템 상태를 변경하기 위해 따를 수 있는 하이퍼미디어 링크가 포함됩니다.모든 이러한 요청은 자원의 표현 등을 받게 됩니다.

중요한 결과는 먼저 요청한 리소스의 식별자만 알고 다른 모든 식별자가 검색된다는 것입니다.즉, 이러한 식별자는 클라이언트에게 미리 알릴 필요 없이 변경될 수 있으며 클라이언트와 서버 간에 느슨한 결합만 존재할 수 있습니다.

역사

OSCON 2008에서 연설하는 로이 필딩(Roy Fielding)

웹은 일반적인 용도의 웹사이트가 이용 가능하게 된 1993-1994년부터 일상적인 용도로 사용되기 시작했습니다.[3]당시에는 웹의 아키텍처에 대한 단편적인 설명만 있었고, 업계에서는 웹 인터페이스 프로토콜에 대한 일부 표준에 합의하라는 압력이 있었습니다.예를 들어, 프록시를 지원하기 위해 몇 가지 실험적 확장이 통신 프로토콜(HTTP)에 추가되었고, 더 많은 확장이 제안되었지만, 이러한 변화의 영향을 평가할 수 있는 공식적인 웹 아키텍처가 필요했습니다.[4]

W3C와 IETF 작업 그룹은 웹의 세 가지 주요 표준인 URI, HTTP, HTML에 대한 공식적인 설명을 만들기 시작했습니다. Roy Fielding은 이러한 표준(특히 HTTP 1.0과 1.1, URI)의 개발에 참여했고, 이후 6년 동안 REST 아키텍처 스타일을 개발했습니다.웹의 프로토콜 표준에 대한 제약 조건을 테스트하고 아키텍처 개선 사항을 정의하고 아키텍처 불일치를 식별하는 수단으로 사용합니다.Fielding은 UC Irvine에서 2000년 박사 학위 논문 "Architectural Styles and the Design of Network-based Software Architecture"[1][5]에서 REST를 정의했습니다.

REST 아키텍처 스타일을 만들기 위해, 필딩은 전세계적인 네트워크 기반 애플리케이션을 만들 때 적용되는 요구사항들을 확인했습니다. 예를 들어, 글로벌 채택이 가능하도록 진입 장벽이 낮아야 한다는 것입니다.또한 네트워크 기반 애플리케이션을 위한 기존의 많은 아키텍처 스타일을 조사하여 캐싱 및 클라이언트-서버 기능과 같은 다른 스타일과 공유되는 기능과 REST 고유의 기능(예: 리소스 개념)을 파악했습니다.Fielding은 현재 구현의 기존 아키텍처를 분류하고 웹의 동작 및 성능 요구사항의 중심으로 고려해야 하는 측면을 파악하려고 했습니다.

그 특성상, 아키텍처 스타일은 특정 구현과 독립적이며, REST가 웹 표준 개발의 일부로 만들어졌지만, 웹의 구현이 REST 아키텍처 스타일의 모든 제약 조건을 따르지는 않습니다.불일치는 무지나 감독으로 인해 발생할 수 있지만 REST 아키텍처 스타일이 존재한다는 것은 표준화되기 전에 식별할 수 있다는 것을 의미합니다.예를 들어, Fielding은 URI에 세션 정보를 포함하는 것을 공유 캐싱 및 서버 확장성에 부정적인 영향을 미칠 수 있는 REST의 제약 조건 위반으로 식별했습니다.또한 HTTP 쿠키는 브라우저의 응용 프로그램 상태와 동기화되지 않아 신뢰할 수 없게 될 수 있으므로 REST 제약 조건을 위반했습니다. 또한 개인 정보 보호 및 보안에 문제가 될 수 있는 불투명한 데이터도 포함하고 있습니다.

건축물의 특성

REST 아키텍처 스타일은 네트워크 기반 응용프로그램, 특히 클라이언트-서버 응용프로그램을 위해 설계되었습니다.그러나 그 이상으로, 인터넷 규모의 사용을 위해 설계되었기 때문에, 대규모 도입을 용이하게 하기 위해서는 사용자 에이전트(클라이언트)와 오리진 서버 간의 결합이 최대한 느슨해야 합니다.

클라이언트와 서버의 강력한 분리와 통일된 주소 지정 프로토콜을 사용한 텍스트 기반의 정보 전송은 웹의 요구 사항을 충족시키기 위한 기초를 제공했습니다: 강건성(무정부적 확장성), 컴포넌트의 독립적인 배치, 많은 양의 데이터 전송, 그리고 콘텐츠 판독기에 대한 낮은 진입 장벽.콘텐츠 제작자와 개발자를 막론하고

REST 건축양식으로 표현된 개념의 개체-관계 모델

REST 아키텍처 스타일의 제약 조건은 다음과 같은 아키텍처 속성에 영향을 미칩니다.[1][6]

  • 사용자가 인식하는 성능과 네트워크 효율성의 주요 요소가 될 수 [7]있는 구성 요소 상호 작용의 성능
  • 많은 수의 구성 요소와 구성 요소 간 상호 작용을 지원할 수 있는 확장성
  • 균일한 인터페이스의 단순성.
  • 애플리케이션이 실행되는 동안에도 변화하는 요구에 맞게 구성요소를 수정할 수 있습니다.
  • 서비스 에이전트에 의한 구성요소 간 통신 가시성
  • 데이터와 함께 프로그램 코드를 이동하여 부품의 휴대성
  • 구성 요소, 커넥터 또는 데이터 내의 고장이 있는 경우 시스템 수준에서 고장에 대한 저항력의 신뢰도.[7]

건축학적 제약조건

REST 건축 양식은 6가지 안내 제약 조건을 정의합니다.[6][8]이러한 제약 조건을 시스템 아키텍처에 적용하면 성능, 확장성, 단순성, 수정 가능성, 가시성, 이식성, 신뢰성 등 바람직한 비기능적 특성을 얻을 수 있습니다.[1]

공식 REST 제약 조건은 다음과 같습니다.

클라이언트-서버 아키텍처

참고 항목:클라이언트-서버 모델

클라이언트-서버 설계 패턴은 사용자 인터페이스 문제와 데이터 스토리지 문제를 분리하는 관심사 분리 원칙을 적용합니다.따라서 사용자 인터페이스의 휴대성이 향상됩니다.웹의 경우, 서버 구현에 대한 지식 없이 대부분의 플랫폼을 위해 수많은 웹 브라우저가 개발되었습니다.분리는 서버 구성요소를 단순화하여 확장성을 향상시키지만, 보다 중요한 것은 구성요소가 독립적으로 진화할 수 있도록 하기 때문이며, 이는 여러 조직 도메인을 포함하는 인터넷 규모 환경에서 필요합니다.

무국적자

참고 항목:상태 비저장 프로토콜

컴퓨팅에서 상태 비저장 프로토콜(stately protocol)은 수신기(일반적으로 서버)에 의해 세션 정보가 유지되지 않는 통신 프로토콜입니다.클라이언트는 세션의 이전 패킷에서 컨텍스트 정보 없이 전송된 모든 정보 패킷을 분리하여 이해할 수 있도록 관련 세션 데이터를 수신기로 전송합니다.이러한 상태 비저장 프로토콜 속성은 대용량 애플리케이션에서 이상적인 프로토콜이며, 세션 정보 보존으로 인한 서버 부하를 제거하여 성능을 향상시킵니다.

현금화 가능성

참고 항목:웹 캐시

월드 와이드 웹에서와 마찬가지로 클라이언트와 중개자는 응답을 캐시할 수 있습니다.응답은 암묵적으로 또는 명시적으로 캐시 가능 또는 비캐시 가능으로 정의하여 클라이언트가 추가 요청에 대해 오래되거나 부적절한 데이터를 제공하지 못하도록 해야 합니다.캐싱이 잘 관리되면 클라이언트와 서버 간의 상호 작용이 일부 또는 완전히 제거되므로 확장성과 성능이 더욱 향상됩니다.캐시는 메모리 또는 브라우저 캐시 스토리지의 클라이언트 시스템에서 수행할 수 있습니다.또한 CDN(Content Delivery Network)에 캐시를 저장할 수도 있습니다.

층계

참고 항목:층계

클라이언트는 일반적으로 엔드 서버에 직접 연결되어 있는지 또는 도중에 중개자에 연결되어 있는지 알 수 없습니다.프록시 또는 로드 밸런서가 클라이언트와 서버 사이에 배치되면 통신에 영향을 주지 않으며 클라이언트 또는 서버 코드를 업데이트할 필요가 없습니다.중간 서버는 로드 밸런싱을 실행하고 공유 캐시를 제공함으로써 시스템 확장성을 향상시킬 수 있습니다.또한 웹 서비스 위에 하나의 계층으로 보안을 추가하여 비즈니스 로직과 보안 로직을 분리할 수 있습니다.[9]보안을 별도의 계층으로 추가하면 보안 정책이 적용됩니다.마지막으로, 중개 서버는 클라이언트에 대한 응답을 생성하기 위해 다른 여러 서버를 호출할 수 있습니다.

주문형 코드(옵션)

참고 항목:클라이언트측 스크립팅

서버는 실행 가능한 코드(예: 자바 애플릿과 같은 컴파일된 구성 요소 또는 자바 스크립트와 같은 클라이언트 측 스크립트)를 전송하여 클라이언트의 기능을 일시적으로 확장하거나 사용자 지정할 수 있습니다.

균일계면

균일한 인터페이스 제약은 RESTful 시스템 설계의 기본입니다.[1]아키텍처를 단순화하고 분리하여 각 부분을 독립적으로 발전시킬 수 있습니다.이 균일한 인터페이스에 대한 네 가지 제약 조건은 다음과 같습니다.

  • 요청 내 리소스 식별:RESTful 웹 서비스에서 URI를 사용하는 등 요청에서 개별 리소스가 식별됩니다.리소스 자체는 클라이언트에 반환되는 표현과는 개념적으로 별개입니다.예를 들어, 서버는 데이터베이스에서 HTML, XML 또는 JSON으로 데이터를 보낼 수 있는데, 이 중 어느 것도 서버의 내부 표현이 아닙니다.
  • 표현을 통한 리소스 조작:클라이언트가 연결된 메타데이터를 포함하여 리소스 표현을 보유할 경우 리소스 상태를 수정하거나 삭제할 수 있는 충분한 정보가 있습니다.
  • 자체 설명 메시지:각 메시지에는 메시지 처리 방법을 설명하기에 충분한 정보가 포함되어 있습니다.예를 들어 호출할 파서는 미디어 유형으로 지정할 수 있습니다.[1]
  • 애플리케이션 상태 엔진으로서의 하이퍼미디어(HATEOAS) - REST 애플리케이션을 위한 초기 URI(웹 사용자가 웹 사이트의 홈 페이지에 액세스하는 것과 유사) - REST 클라이언트는 서버가 제공하는 링크를 동적으로 사용하여 필요한 모든 가용 리소스를 검색할 수 있어야 합니다.액세스가 진행되면 서버는 현재 사용 가능한 다른 리소스에 대한 하이퍼링크가 포함된 텍스트로 응답합니다.클라이언트가 서버의 구조에 관한 정보를 하드코딩할 필요는 없습니다.[10]

분류모델

REST 설계의 다양한 원칙에 따라 REST API를 분류하는 데 도움이 되는 여러 모델이 개발되었습니다.

웹 서비스에 적용됨

REST 아키텍처 제약을 따르는 웹 서비스 API를 RESTful API라고 합니다.[13]HTTP 기반 RESTful API는 다음과 같은 측면으로 정의됩니다.[14]

  • 시작점으로 사용되는 하나 또는 여러 리소스의 리소스 식별자(URI)(때로는 끝점 또는 진입점이라고도 함)
  • 가능한 모든 리소스 표현의 인코딩(상태 전환을 위한 데이터 및 하이퍼미디어 링크 표현 포함)
  • 가능한 상태 전이와 그것들이 일어날 수 있는 곳.

SOAP 기반 웹 서비스와 달리 RESTful 웹 API에 대한 "공식" 표준은 없습니다.REST는 건축 양식인 반면 SOAP는 프로토콜이기 때문입니다.REST는 그 자체로 표준은 아니지만 RESTful 구현에서는 HTTP, URI, JSON, XML 등의 표준을 사용합니다. 많은 개발자들은 이러한 API가 위에서 설명한 아키텍처 제약(특히 균일한 인터페이스 제약)을 모두 충족하지는 못하더라도 RESTful이라고 설명합니다.[2]RESTful이라고 주장하는 대부분의 API는 실제로 Richardson Matility Model의 레벨 2만을 만족합니다.

참고 항목

참고문헌

  1. ^ a b c d e f Fielding, Roy Thomas (2000). "Chapter 5: Representational State Transfer (REST)". Architectural Styles and the Design of Network-based Software Architectures (Ph.D.). University of California, Irvine. Archived from the original on 2021-05-13. Retrieved 2004-08-17.
  2. ^ a b Fielding, Roy T. (2008-10-20). "REST APIs must be hypertext driven". roy.gbiv.com. Archived from the original on 2010-03-18. Retrieved 2016-07-06.
  3. ^ Couldry, Nick (2012). Media, Society, World: Social Theory and Digital Media Practice. London: Polity Press. p. 2. ISBN 9780745639208.
  4. ^ Fielding, Roy Thomas (2000). "Chapter 6: Experience and Evaluation". Architectural Styles and the Design of Network-based Software Architectures (Ph.D.). University of California, Irvine. Archived from the original on 2023-03-26. Retrieved 2023-06-21.
  5. ^ "Fielding discussing the definition of the REST term". groups.yahoo.com. Archived from the original on November 5, 2015. Retrieved 2017-08-08.
  6. ^ a b Erl, Thomas; Carlyle, Benjamin; Pautasso, Cesare; Balasubramanian, Raj (2012). "5.1". SOA with REST: Principles, Patterns & Constraints for Building Enterprise Solutions with REST. Upper Saddle River, New Jersey: Prentice Hall. ISBN 978-0-13-701251-0.
  7. ^ a b Fielding, Roy Thomas (2000). "Chapter 2: Network-based Application Architectures". Architectural Styles and the Design of Network-based Software Architectures (Ph.D.). University of California, Irvine. Archived from the original on 2014-12-16. Retrieved 2014-04-12.
  8. ^ Richardson, Leonard; Ruby, Sam (2007). RESTful Web Services. Sebastopol, California: O'Reilly Media. ISBN 978-0-596-52926-0.
  9. ^ Lange, Kenneth (2016). The Little Book on REST Services. Copenhagen. p. 19. Archived from the original on 18 August 2019. Retrieved 18 August 2019.{{cite book}}: CS1 유지 관리: 위치 누락 게시자(링크)
  10. ^ Gupta, Lokesh (2 June 2018). "REST HATEOAS". REST API Tutorial. RESTfulAPI.net. Archived from the original on 7 April 2019. Retrieved March 10, 2019.
  11. ^ "Classification of HTTP APIs". algermissen.io. Archived from the original on 2023-01-29. Retrieved 2023-01-29.
  12. ^ Ivan Salvadori, Frank Siqueira (June 2015). "A Maturity Model for Semantic RESTful Web APIs". Conference: Web Services (ICWS), 2015 IEEE International Conference OnAt. New York – via Researchgate.
  13. ^ Gupta, Lokesh. "What is REST API". RESTful API Tutorial. Archived from the original on 2 October 2016. Retrieved 29 September 2016.
  14. ^ Richardson, Leonard; Amundsen, Mike (2013), RESTful Web APIs, O'Reilly Media, ISBN 978-1-449-35806-8


추가열람