Representational Action State Transfer

Representational Action State Transfer (REAST) is a refinement of REST (REpresentational State Transfer) with one additional constraint, that is to confine the representation and transfer of resource between a client and the resource's server to only the representation and transfer of the Action State of resource.
Today, typical RESTful implementations represent and transfer the data state of server-side resources. When a request of a specified server-side resource is made from a client, the server takes the data state representation of the resource at the point in time, and transfers it as a response object to the client for rendering.
REAST does not concern about the data-states of resource representations and transfers. Instead, REAST concerns about the Action-state of resource representations and transfers between the requesting client and the server of the resource.
Motivations
The motivation of REAST is to enable web users for Web tasking:
* by web interactions without any programming requirement nor any dependency on programmers
* to enable web users to delegate their web interactions for tasks to machines for web automation and/or for future execution.
Today's representations and transfers of data-state of resources result in the following restrictions in web interactions for web tasking as individual users:
* Server-side constructed response to all clients result in Homogenous interactions for all users without room for situational permutations of web interactions for web tasking as individual web users
* Server-side constructed response results in web users' experience of silo interactions with resources across different distributed domains
* Web interactions today are user dependent. If web users do not initiate a request, nothing is being done across the web for the user
* Web interactions are disjoint across different interaction devices
History
A hypermedia link between two representations of data states of two distributed resources is easily understood in the context of Web Browsing. Web user is being rendered the response object that contains the data-state representation of the first distributed resource that he or she requested, then he or she chooses one from all available hypermedia links to request the next distributed resource's data-state representation.
However, the semantics of a hypermedia link between two representations of data states of two distributed resources in the context of Web tasking under the RESTful constraint of HATEOAS is undefined.
Various existing solutions to this issue share the general approach of providing a meta-model of domain specific definitions of links or link-types (such as “pay”, “order” etc.) to establish link semantic convention for participants. However, because not all participants of the web share the domain-specific link semantic definitions, it does not work generically across the web.
REAST is to address the absence of universal semantic definition for the hypermedia link in the context of Web tasking. The term "REAST" was originally coined by Joanna W. Ng from IBM Canada CAS Research, in an article published in November 2013, titled “From Representational State Transfer (REST) to Representational Action State Transfer (REAST),”
How REAST Enables Web tasking
REAST operates within the paradigm of action states representations of distributed re-sources. Therefore, in REAST, a link between two action-state representational instances (of distributed resources) is well defined for its generic, universal purpose, function and semantics across the web: web task is expressed and executed as a transition from one action state of a given distributed resource to another action state of another distributed resource within a RESTful, HATEOAS architectural style of the web. For example, the response of the action (e.g. Create) of the source resource (e.g. Order) is to invoke, complying with the target action-condition, the action (e.g. Create) of the target resource (e.g. Payment). Consequently, REAST has universal operability across RESTful resources across the web without any domain specificity.
REAST enables an Interactive Representation of server Resources (IRR). Server resources are represented as REAST IRR resources. Users perform web interactions to express how and when and what IRR he or she wants to interact with, captured as REAST instances being sent to the REAST runtime component. The REAST run time component will process and create these web interactions on behalf of web users.

Main Menu

See Also

Main Menu