REST 개념

REST ( Representational state transfer )

 

World Wide Web 아키텍처의 설계 및 개발을 안내하기 위해 만들어진 소프트웨어 아키텍처 스타일.

소프트웨어 아키텍처란 그 시스템의 한 구조나 구조들로 각 요소들과 외부에 보이는 특성들 그리고 그들 간의 관계를 절충한다.

http://www.kosta.or.kr/mail/2014/download/SW_Architecture_Model.pdf

REST는 웹과 같은 인터넷 규모 분산 하이퍼미디어 시스템의 아키텍처가 어떻게 작동해야 하는지에 대한 일련의 제약 조건을 정의.

하이퍼미디어 :: 하이퍼 텍스트 라는 용어의 확장인 하이퍼미디어 는 그래픽, 오디오, 비디오, 일반 텍스트 및 하이퍼링크 를 포함하는 정보 의 비선형 매체

REST 아키텍처 스타일은 구성 요소 간의 상호 작용 확장성, 균일한 인터페이스, 구성 요소의 독립적인 배포, 구성 요소 캐싱을 용이하게 하는 계층형 아키텍처 생성을 강조하여 사용자가 인지하는 것을 줄인다.

(대기 시간, 보안강화, 레거시 시스템 캡슐화)

 

REST는 소프트위어 산업 전반에 걸쳐 채택되어 왔으며 안정적인 상태 비저장 웹 API 를 생성하기 위해 널리 인정되는 일련의 지침.

REST 제약 조건을 준수하는 웹 API 는 비공식적으로 RESTful로 설명됨

RESTful 웹 API는 일반적으로 URL 인코딩 매개변수를 통해 리소스에 엑세스 하는 HTTP 메서드와 데이터 전송을 위한 JSON 또는 XML 사용을 기반으로 한다.

 

웹 리소스 ::

 World Wide Web 에서 URL로 식별되는 문서 또는 파일로 처음 정의.

 오늘 날의 정의는 훨씬 더 일반적이고 추상적이며 웹에서 어떤 방식으로든 식별, 명명, 주소 지정, 처리 또는 수행할 수 있는 모든 사물, 엔티티 또는 작업을 포함한다.

RESTful 웹 서비스에서 리소스의 URI에 대한 요청은 HTML, XML, JSON 또는 기타 형식으로 형식화된 페이로드로 응답을 이끌어 낸다.

통일 자원 식별자 ( URI가 ) 식별 논리적 또는 물리적 자원이 웹 기술에서 사용하는 것으로 문자의 고유 한 순서. URI는 사람 및 장소와 같은 실제 개체, 개념 또는 웹 페이지 및 책과 같은 정보 리소스를 포함하여 모든 것을 식별하는 데 사용할 수 있다.

예를 들어, 응답은 리소스 상태가 변경되었음을 확인할 수 있다. 응답에는 하이퍼텍스트도 포함될 수 있다. 관련 리소스에 대한 링크. 이러한 요청 및 응답에 대한 가장 일번적인 프로토콜은 HTTP (GET, POST, PUT, DELETE와 같은 작업 (HTTP 메소드))를 제공한다.

RESTful 시스템은 상태 비저장 프로토콜과 표준 작업을 사용하여 시스템이 실행되는 동안에도 시스템 전체에 영향을 주지 않고 관리 및 업데이트할 수 있는 구성 요소를 재사용함으로써 빠른 성능, 안정성 및 성장 능력을 목표로 함.

 

REST의 목표는  성능, 확장성, 단순성, 수정 가능성, 가시성, 이식성 및 안정성을 높이는 것.

이는 다음 REST 원칙을 통해 달성된다

클라이언트 - 서버 아키텍처, 상태 비저장, 캐시 가능성, 계층화된 시스템 사용, 주문형 코드 지원 및 균일한 인터페이스 사용

 

 

간단요약

자원을 이름으로 구분하여 해당 자원의 상태를 주고 받는 모든 것을 의미

ex) 표현 : 데이터, 그림, 문서 등 의 소프트웨어 자원

DB의 학생 정보가 자원일 때, 'students'이 자원이 이름(표현) 

ex) 이동 :  데이터를 요청할 때, 자원의 상태를 전달

JSON 이나 XML를 통해서 데이터를 주고 받는 것이 많다.

 

*JSON :: 전달, 응답 다쓰지만 보통 전달할 때 많이 사용

*XML :: 전달, 응답 다쓰지만 보통 응답할 때 많이 사용

---

History

아키텍처 스타일은 특정 구현과 무관하며 REST는 웹 표준 개발의 일부로 만들어졌지만 웹 구현은 REST 아키텍처 스타일의 모든 제약 조건을 따르지 않는다.

무지나 부주의로 인해 불일치가 발생할 수 있지만 REST 아키텍처 스타일의 존재는 표준화되기 전에 식별할 수 있음을 의미한다.

Fielding은 (사람임ㅋ) URI에 세션 정보를 포함하는 것을 공유 캐싱 및 서버 확장성에 부정적인 영향을 줄 수있는 REST 제약 조건 위반으로 식별했다. 또한 HTTP 쿠키는 우려할 수 있는 불투명한 데이터를 포함한다.(개인 정보 보호 및 보안)

 

---

아키텍처의 개념

REST 아키텍처 스타일은 네트워크 기반 애플리케이션, 특히 클라이언트 - 서버 애플리케이션을 위해 설계됨.

그러나 그 이상으로 인터넷 규모의 사용을 위해 설계되어서 사용자 에이전트(클라이언트) 와 원본 서버 간의 결합은 대규모 채택을 용이하게 하기 위해 가능한 한 가볍게(느슨하게) 해야한다.

이는 엔티티 를 캡슐화 하는 리소스 를 정의하여 서버에 추상화 계층을 생성함으로써 달성된다.

ex) 파일 = 서버에 있으므로 기본 구현 세부 정보 (파일 서버, 데이터베이스 등)을 숨김.

 

이름을 지정할 수 있는 모든 정보는 리소스가 될 수 있다. 

 

클라이언트는 URI를 사용하여 리소스에만 액세스할 수 있다 . 

즉, 클라이언트는 URI를 사용하여 리소스를 요청하고 서버는 리소스 의 표현 으로 응답.

 

리소스의 표현은 REST의 또 다른 중요한 개념. 

가능한 가장 많은 수의 클라이언트 응용 프로그램에서 응답을 해석할 수 있도록 하기 위해 리소스 표현이 하이퍼텍스트 형식으로 전송.

따라서 리소스는 클라이언트와 서버 간의 메시지 로 전송되는 하이퍼텍스트 표현을 통해 조작된다 .

균일한 주소 지정 프로토콜을 사용하는 텍스트 기반 정보 전송과 함께 클라이언트와 서버의 강력한 분리는 웹의 요구 사항을 충족하기 위한 기반을 제공했다. (콘텐츠 독자, 콘텐츠 작성자 및 개발자 모두를 위한 낮은 진입 장벽.)

 

---

아키텍처 속성

 

• 사용자가 인식하는 성능과 네트워크 효율성의 지배적인 요소가 될 수 있는 구성 요소 상호 작용의 성능
• 많은 수의 구성 요소 및 구성 요소 간의 상호 작용을 지원하는 확장성
• 균일한 인터페이스의 단순성
• 변화하는 요구 사항을 충족하기 위한 구성 요소 수정 가능성(응용 프로그램이 실행되는 동안에도)
• 서비스 에이전트에 의한 구성 요소 간의 통신 가시성
• 데이터와 함께 프로그램 코드를 이동하여 구성 요소의 이식성
• 구성 요소, 커넥터 또는 데이터에 오류가 있는 경우 시스템 수준에서 오류에 대한 저항의 신뢰성

 

---

아키텍처 제약 조건

아키텍처 스타일은 6가지의 제약 조건을 정의한다.

이러한 제한은 시스템 구조에 적용되며, 이는 비 기능적 특성 등의 성능, 확장성, 단순성, 개질(선)성, 시인성, 이동성, 안정성 등의 바람직한 기능을 얻는다.

이러한 제약 조건중 일부 또는 전부를 준수하는 시스템을 RESTful이라고 한다.

 

클라이언트 - 서버 아키텍처 (Client–server architecture) ::  클라이언트 - 서버 모델

 

클라이언트 - 서버 디자인 패턴은 사용자 인터페이스 문제를 데이터 저장 문제와 분리하는 문제 분리 원칙을 적용한다.

따라서 사용자 인터페이스의 이식성이 향상된다. 웹의 경우, 웹 브라우저의 과다한 모든 서버 구현에 대한 지식이 필요없이 대부분의 플랫폼을 위해 개발되었다. 또한 분리는 서버 구성 요소를 단순화하여 확장성을 개선하지만 더 중요한 것은 구성 요소가 독립적으로 발전할 수 있도록 하는 것(무상태,무정부적 확장성)이며, 이는 여러 조직의 도메인을 포함하는 인터넷 규모 환경에서 필요하다.

 

무상태 (무국적, 불분명한)(Statelessness) :: 상태 비저장 프로토콜

 

컴퓨팅에서 상태 비저장 프로토콜은 세션 정보가 수신자, 일반적으로 서버에 의해 유지되지 않는 통신 프로토콜.

관련 세션 데이터는 전송된 모든 정보 패킷이 세션의 이전 패킷에서 컨텍스트 정보 없이 분리되어 이해될 수 있는 방식으로 클라이언트에 의해 수신기로 전송된다. 상태 비저장 프로토콜의 이러한 속성은 대용량 응용 프로그램에 이상적이며 세션 정보 보존으로 인한 서버 부하를 제거하여 성능을 향상 시킨다.

 

캐시성, 캐시가능성 (Cacheability) :: 웹 캐시

 

World Wide Web에서와 같이 클라이언트와 중개자는 응답을 캐시할 수 있다. 응답은 클라이언트가 추가 요청에 대한 응답으로 부실하거나 부적절한 데이터를 제공하는 것을 방지하기 위해 암시적 또는 명시적으로 자신을 캐시 가능 또는 캐시 불가능으로 정의해야한다. 잘 관리된 캐싱은 일부 클라이언트 - 서버 상호 작용을 부분적으로 또는 완전히 제거하여 확장성과 성능을 더욱 향상시킨다.

 

계층화 시스템 (Layered system) :: 계층화된 시스템

 

클라이언트는 일반적으로 종단(엔드) 서버에 직접 연결되어 있는지 아니면 도중에 중개자와 연결되어 있는지 알 수 없다.

그런 경우 프록시 또는 부하 분산 장치는 클라이언트와 서버 사이에 위치하고 그것은 그것들의 통신에 영향을 미치지 않는다, 클라이언트 또는 서버 코드를 업데이트 할 필요가 없을 것이다. 중간 서버는 로드 밸런싱을 활성화하고 공유 캐시를 제공하여 시스템 확장성을 향상시킬 수 있다. 또한 웹 서비스 위에 보안을 추가하여 비즈니스 로직과 보안 로직을 분리 할 수 있다. 보안을 별도의 계층으로 추가하면 보안 정책이 적용된다. 마지막으로 중개 서버는 여러 다른 서버를 호출하여 클라이언트에 대한 응답을 생성할 수 있다. 

 

요청시 코드 (옵션) / 주문형 코드(선택사항) (Code on demand (optional)) :: 클라이언트 측 스크립팅

 

서버는 실행 코드를 전송하여 클라이언트의 기능을 일시적으로 확장하거나 사용자 정의할 수 있다.

(예: Java 애플릿 과 같은 컴파일된 구성 요소 또는 JavaScript 와 같은 클라이언트 측 스크립트) .

 

균일한(통일된) 인터페이스 (Uniform interface)

 

균일한 인터페이스 제약은 모든 RESTful 시스템 설계의 기본

아키텍처를 단순화하고 분리하여 각 부분이 독립적으로 발전할 수 있도록 하는데, 균일한 인터페이스에 대한 네 가지 제약 조건은 다음과 같다.

 

• 요청에서 리소스 식별

• 개별 리소스는 예를 들어 RESTful 웹 서비스에서 URI를 사용하여 요청에서 식별된다.
• 리소스 자체는 클라이언트에 반환되는 표현과 개념적으로 별개.
• 예를 들어, 서버는 데이터베이스에서 HTML, XML 또는 JSON으로 데이터를 보낼 수 있는데, 이 중 어느것도 서버의 내부 표현이 아님.

 

• 표현을 통한 리소스 조작

• 클라이언트가 연결된 메타데이터를 포함하여 리소스의 표현을 보유할 때 리로스의 상태를 수정하거나 삭제하기에 충분한 정보를 가지고 있다.

 

• 자체 설명 메세지

• 각 메세지에는 메세지 처리 방법을 설명하기에 충분한 정보가 포함되어 있다.
• 예를 들어 호출할 팔서를 미디어 유형으로 지정할 수 있다.

 

• 애플리케이션 상태의 엔진으로서의 하이퍼 미디어( HATEOAS )

• 웹 사이트의 홈페이지에 엑세스하는 인간 웹 사용자와 유사하게 REST 애플리케이션의 초기 URI에 엑세스 한 REST 클라이언트는 서버가 제공한 링크를 동적으로 사용할 수 있어야 한다. 필요한 모든 사용 가능한 리소스를 검색한다. 엑세스가 진행됨에 따라 서버는 현재 사용 가능한 다른 리소스에 대한 하이퍼링크가 포함된 텍스트로 응답한다. 클라이언트가 애플리케이션의 구조나 역학에 관한 정보로 하드코딩할 필요가 없다.
• 단순하게) 그냥 클라이언트는 API 서버에 있는 정보를 끌어오면 된다.

 

---

웹 서비스에 적용 ( Applied to web services )

REST 아키텍처 제약 조건을 준수하는 웹 서비스를 RESTful API라고 한다.

HTTP 기반 RESTful API 는 다음과 같은 측면으로 정의된다.

 

• http://api.example.com/; 과 같은 기본 URI
• 표준 HTTP 메소드 (ex. GET, POST, PUT 및 DELETE)
• 상태 전이 데이터 요소를 정의 하는 미디어 유형 ( ex. Atom, microformats, application/vnd.collection+json 등). 현재 표현은 클라이언트에게 다음 사용 가능한 모든 애플리케이션 상태로의 전환 요청을 구성하는 방법을 알려준다.이것은 URI처럼 간단할 수도 있고 Java 애플릿처럼 복잡할 수도 있다.

 

HTTP 메소드의 의미

다음 표는 RESTful을 포함하여 HTTP API에서 HTTP 메소드가 어떻게 사용되는지 보여준다.

HTTP 메소드		설명
GET	대상 리소의 상태를 나타낸다.
POST	대상 리소스가 요청에 포함된 표현을 처리하도록 한다.
PUT	대상 리소스가 상태를 요청에 포함된 표현으로 정의된 상태로 만들거나 바꾼다.
DELETE	대상 리소스의 상태를 삭제한다.

 

• GET 메서드는 안전하므로 리로스에 적용해도 리소스의 상태가 변경되지 않는다. (읽기 전용 의미 체계)
• GET, PUT 및 DELETE 메소드는 멱등적이다. 즉, 응답은 다를 수 있지만 리소스에 여러 번 적용하면 리소스의 상태가 한 번 적용할 때와 동일한 상태로 변경된다.
• GET 및 POST 메소드는 캐시 가능하며, 이는 이에 대한 응답을 향후 재사용을 위해 저장할 수 있음을 의미한다.

멱등 : 수학 및 컴퓨터 과학의 특정 연산의 속성으로, 초기 적용을 넘어 결과를 변경하지 않고 여러 번 적용할 수 있다. 멱등성의 개념은 추상 대수학 및 함수 프로그래밍의 여러 곳에서 발생한다.

 

 

 

참고, 출처

https://en.wikipedia.org/wiki/Dynamic_web_page#Client-side_scripting

Dynamic web page - Wikipedia

 

참고하면 좋은 사이트

https://meetup.toast.com/posts/92

REST API 제대로 알고 사용하기 : NHN Cloud Meetup