REST - Roy Fielding dissertation 번역 요약

참고자료

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

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

https://johngrib.github.io/wiki/REST-paper-summary/#chapter-5-representational-state-transfer-rest

---

Deriving REST

architecture style에 제한을 추가함으로써 더 나은 새로운 architecture style을 만들 수 있다.

REST가 architectural style로 정착이 되는걸 훑으면서 REST에 대한 이해를 높일 수 있을 것이다.

 

Starting with the Null Style

architectural design을 할 때 두 가지 관점이 있다.

하나는 빈 곳에서 시작하여 원하는 시스템의 조건을 충족시킬때까지 architecture을 만드는 것이다.

다른 하나는 제한이 없던 시스템에서 출발하여 제한을 추가하면서 원하는 시스템으로 만드는 것이다.

첫번째 방법은 창의성을 중시하고, 두번째 방법은 제한과 시스템 context에 대한 이해를 중시한다.

 

REST는 두번째 방법에 의해서 발전되어 왔다.

 

Client-Server

첫번째로 추가된 제한은 Client-server architectural style이다.

유저 인터피에스와 데이터 저장을 분리함으로써 여러 플랫폼에서의 이식성을 높이고 서버를 단순화시켜 scale up 하기도 쉽게 하였다.

웹에서는 이런 분리가 독립적인 진화를 가능하게 하였다.

 

 

Stateless

다음으로 추가된 제한은 client-sever의 interaction에 추가되었다.

커뮤니케이션은 stateless여야만 하고 client로부터 서버로 가는 각 request들은 request를 이해할 때 필요한 모든 정보를 포함하고 있어야 하며 server에 저장된 어떠한 context에 의해서도 advantage를 받으면 안된다.

따라서 Session state는 client에 의해서만 관리된다.

 

이 제한은 visibility, reliability, scalability의 속성을 향상시킨다.

Visibility는 하나의 request를 너머서 볼 필요성이 없어지기에 향상된다.

Reliability는 부분적인 failures로부터 task의 복구가 쉬워 향상된다.

Scalability는 reqeust들로부터 state를 저장할 필요가 없고 implementation도 단순화 시켜 서버가 자원을 적게 쓸 수 있다.

 

대부분의 architecture들이 그렇듯이 stateless도 trade-off가 있다. stateless는 반복되는 data에 의하여 network performance를 감소시킨다(data가 server쪽 context에 저장이 안되니까).

 

Cache

네트워크 효율성을 높이기 위하여 stateless에 cache constraint를 더하게 되었다.

Cache contraint는 response에 담긴 data에 cacheable한지 아닌지 라벨링을 강제한다.

만약 response가 cacheable하면 client의 cache는 나중의 동일한 request에 대해 data를 재사용할 권한을 갖게 된다.

 

cache constraint의 장점은 부분적인 interaction들을 제거하여 효율성과 scalability를 높이고 평균적인 지연을 줄여 user가 느끼는 performance를 향상시켜준다.

그러나 trade-off로 cache에 있는 data가 stale된 경우에도 server로 바로 보낼 수 있어 reliability를 떨어뜨린다.

 

Uniform Interface

Component interface를 도입함으로써 전체적인 시스템 architecture가 단순해지고 interaction의 visibility도 높아졌다.

Implemenation이 서비스를 주는 쪽과 decoupled 되면서 독립적인 발전이 가능해졌다.

Trade-off는 uniform interface가 정보들이 표준화되어 이동하다 보니 효율성을 낮아졌다.

REST는 Web의 흔한 case와 hypermedia data 전송에 효율적이나 다른 형태의 architectural interaction에 최적화된 것은 아니다.

 

uniform interace를 위해 component들의 behavior에 대해서 여러 architectural 제한들이 더 요구된다.

• identification of resources
• manipulation of resources through representations
• self-descriptive messages
• hypermedia as the engine of application state

Layered System

internet-scale에서의 성능 향상을 위해 Layered system constraints을 추가했다.

layered system style은 component들을 제한시켜(예를 들면 각 component는 자신과 소통하고 있는 layer의 너머를 보지 못한다) architecture을 구조적인 layer들로 이뤄지게 한다.

한 layer의 knowledge를 제한시켜 전체적인 시스템의 복잡도를 제한시키고 독립성을 촉진시킨다.

Layer는 legacy service들을 캡슐화시키고 새로운 서비스를 legacy client로부터 보호한다.

또한 자주 사용되지 않는 기능을 공유되는 intermediary로 이동시켜 component들을 단순화 시킨다.

Intermediary는 여러 네트워크와 프로세서들 사이에서 로브 밸런싱을 수행해 시스템 scalability를 높일 때 사용되기도 한다.

 

Layered system의 가장 큰 단점은 데이터를 처리할 때 오버헤드와 지연이 생겨 유저가 느끼는 performance를 떨어뜨릴 수 있다.

Cache constraints을 지원하는 network-based system의 경우 intermediaries의 shared caching의 이득으로 이는 상쇄된다. organizational domain의 경계에 공유되는 cache를 놓는 것은 큰 performance 향상을 낳는다.

 

Layered system과 uniform interface constraints의 조합으로 architectural 속성들은 uniform pipe-and-filter style과 흡사해진다. REST interaction은 two-way 인데도도 불구하고, hypermedia interacion은 data-flow network처럼 처리된다. filter component들이 선택적으로 data stream에 적용을 함으로써 컨텐츠가 전달될 때 변환시킬 수 있기 때문이다.

REST에서는 intermediary component들이 content들의 메시지를 actively하게 바꿀 수 있다. 왜냐하면 메시지들은 self-descriptive하고 의미가 intermediary에게 visible 하기 때문이다.

 

Code-On-Demand

REST는 client에게 코드(애플릿, 스크립트 형태)를 다운로드하고 실행할 수 있게 하였다.

이로써 client는 수 많은 속성들을 미리 준비할 필요가 없어졌다. 그러나 이는 visibility를 감소시켜 REST에 optional한 constraint이다.

 

 

---

REST Architectural Elements

REST는 분산된 hypermedia system에 있는 architectural element들의 추상화이다.

REST는 component의 자세한 implementation과 프로토콜을 무시하고 component의 역할, 다른 component과의 interaction에 대한 constraint, data element들에 대한 해석에 집중한다.

REST는 웹 아키텍처의 기초를 정의하는 component, connector 및 데이터에 대한 근본적인 제약 조건을 포함한다.

 

Data Elements

모든 데이터가 처리 component들에 캡슐화되고 숨겨지는 distributed object style과는 달리, architecture의 data element들의 특성과 상태는 REST의 키이다.

distributed hypermedia의 특성에서 영향을 받은 것으로 보여진다.

distributed hypermedia architect는 다음과 같은 옵션이 있다.

• 데이터가 있는 곳에 데이터를 렌더링하고 수신자에게 fixed-format image를 전송한다.
• 렌더링 엔진으로 데이터를 캡슐화하여 수신자에게 전송한다.
• 아니면 데이터 유형을 설명하는 메타데이터와 함께 수신자에게 원시 데이터를 전송한다

REST는 meta data로 data type을 공유하는데 초점을 맞추어 범위를 표준화된 인터페이스로 보여지게 좁혀 위 세가지의 옵션을 hybrid하게 제공한다. 

REST component들은 수신자의 능력이나 필요, resource의 특성에 따라 동적으로 결정된 standard data type으로 resource representation을 보내준다.

representation이 원본과 동일 포맷인지 아닌지는 인터페이스 뒤에 남아있는 소스에서 구해진다.

고정되어 있지 않은 객체 스타일(the mobile object style)은 캡슐화된 렌더링 엔진의 표준 데이터 형식을 참고하여 구성한 표현(representation)을 전송하여 목표에 접근한다.

 

REST는 이로써 서버 확장성 문제에서도 벗어나면서 client-server style에서 이득을 가져가고, 일반적인 인터페이스 정보를 숨기는 것을 허용해 캡슐화와 서비스의 진화를 가능케하고, 다양한 기능을 제공한다.

 

REST의 data element들은 다음과 같이 요약할 수 있다.

• resource
• resource identifier : ex) URL, URN
• representation : ex) HTML document, JPEG image
• representation metadata: ex) media type, last-modified time
• resource metadata : ex) source link, alternates, vary
• control data : ex) if-modified-since, cache-control

Resources and Resource Identifiers

REST의 핵심 추상화는 resource이다.

이름이 명명되어 질 수 있는 어떤 정보든 resource가 될 수 있다.

resource는 엔티티 집합에 대한 개념적인 mapping이지 어느 순간에 대응되는 엔티티가 아니다.

 

resource에 대한 추상화된 정의는 웹 아키텍쳐의 주된 특성을 가능하게 한다.

• 자원의 타입이나 구현에 영향을 받지 않는 보편성을 제공한다.
• 요청의 특성을 기반으로 content negotiation을 가능하게 할 수 있도록 representaion에 대한 reference의 late binding을 허용한다.
• 해당 개념의 단일 표현이 아닌 개념을 reference 하므로 representation이 바뀌어도 존재하는 모든 링크를 바꿀 필요가 없다.

 

Representation

REST component는 resource의 현재 상태나 의도된 상태를 확인하고 그에 맞는 representation을 다른 component에게 전송하는 방식으로 resource를 다룬다.

Representation은 일련의 byte들과 byte들을 설명하는 metadata representaion으로 이루어져 있다.

 

Representation의 구성은 다음과 같다.

• 데이터
• 데이터를 설명하는 metadata
• metadata를 설명하는 metadata(가끔)

응답 메시지에는 representation meta data와 resource meta data가 모두 포함될 수 있다.

 

제어 데이터(Control data)는 component간 메시지 목적을 정의한다.

요청을 매개 변수화 하고 일부 연결 요소의 기본 동작을 재정의하는데 사용된다.

ex) 제어 데이터를 사용해 캐시 동작을 수정

또한 제어 데이터를 사용해 resource의 현재 상태, 원하는 상태를 표현 가능하다.

 

(여기서부터 지쳐서 참고자료에 올린 이미 요약 번역된 사이트에서 학습)

Media type

• Representation의 data type을 media type이라고 한다.
• representation은 메시지에 포함시킬 수 있다.
• 메시지의 제어 데이터와 media type에 따라 수신자가 처리한다.
• 하나의 메시지에 여러 표현이 들어갈 수 있다.

Connectors

 

REST는 다양한 커넥터 유형을 사용하여 resource access 및 resource representation 전송 활동을 캡슐화

Connector는 component간 통신을 위한 추상 인터페이스를 제공하여 관심사를 분리하고, 기본 구현 resource 및 통신 메커니즘을 숨김으로써 단순성을 향상시켰다.

 

 

REST의 모든 상호 작용은 stateless이다.

각 요청에는 이전 요청과 관계 없이 connector가 요청을 이해하는 데 필요한 모든 정보가 들어있다.

이에 따라 Connector가 요청간에 상태를 유지할 필요가 없고, 병렬 처리가 가능하고, 캐싱이 용이하다.

• 기본 Connector 유형은 client, server이다.
• cache connector는 네트워크 통신 반복을 피하기 위해 server나 client 인터페이스에 위치할 수 있다.
• resolver connector는 resource 식별자를 네트워크 주소 정보로 변환한다.
• tunnel은 통신을 중계한다.

Component

사용자 에이전트

• client connector 이용하여 요청
• 응답의 최종 수신자
• ex) 웹 브라우저

원본 서버(origin server)

• server connector를 이용하여 요청된 resource의 네임 스페이스를 제어
• resource representation에 대한 최종 출처
• resource 값 수정 요청의 최종 수신자
• 각 origin server는 서비스에 대한 자원 인터페이스로 일반 인터페이스 제공
• resource 구현 세부 정보는 인터페이스 뒤에 숨겨져 있다.

중계 컴포넌트

-프록시

• 타 서비스의 인터페이스 캡슐화, 데이터 변환, 성능 향상, 보안 목적으로 client가 선택하는 중개자

-게이트웨이

• 데이터 변환, 성능 향상, 보안에 대해 다른 서비스의 인터페이스 캡슐화를 제공하는 매개체
• 프록시와 게트웨이의 차이점 : 프록시를 사용할 시점은 client가 결정