Functional Augmented State Transfer (FAST) Architecture for Computationally Intensive Network Applications
📝 Abstract
We describe a novel architecture that combines the simplicity of RESTful architecture with the power of functional programming for delivering web-services. Although, RESTful architecture has been quite useful in simplifying the development of scalable systems, it is not suited for all types of network applications. Our architecture improves upon the RESTful architecture to provide scalable framework for computationally intensive network applications. The proposed architecture is ideal for applications that involve data management and data analysis/calculations on data. Data analytics and financial calculations are two areas where the architecture can be applied efficiently.
💡 Analysis
We describe a novel architecture that combines the simplicity of RESTful architecture with the power of functional programming for delivering web-services. Although, RESTful architecture has been quite useful in simplifying the development of scalable systems, it is not suited for all types of network applications. Our architecture improves upon the RESTful architecture to provide scalable framework for computationally intensive network applications. The proposed architecture is ideal for applications that involve data management and data analysis/calculations on data. Data analytics and financial calculations are two areas where the architecture can be applied efficiently.
📄 Content
Functional Augmented State Transfer (FAST) Architecture for Computationally Intensive Network Applications GOPI KRISHNA SUVANAM1 ABSTRACT We describe a novel architecture that combines the simplicity of RESTful architecture with the power of functional programming for delivering web-services. Although, RESTful architecture has been quite useful in simplifying the development of scalable systems, it is not suited for all types of network applications. Our architecture improves upon the RESTful architecture to provide scalable framework for computationally intensive network applications. The proposed architecture is ideal for applications that involve data management and data analysis/calculations on data. Data analytics and financial calculations are two areas where the architecture can be applied efficiently.
Keywords: Web Services, RESTful architecture, functional programming, network applications
1 RESTFUL ARCHITECTURE
RESTful architecture is an architectural style for building
distributed
applications
using
hypermedia.
RESTful
architecture for network applications has been quite
popular because of its simplicity and completeness for use
in many web applications [1]. As a result, RESTful services
have gained an upper hand over SOAP architecture [2].
Especially with the rapid growth in mobile and cloud
computing, RESTful web services have gained more
popularity [3].
The power of RESTful architecture comes from the ability to
decouple the client and the server. The client can access the
services without learning the API in advance. This ensures
scalable development. The client can “browse” through the
API of a server and discover the functionality in runtime as
opposed to knowing the API documentation in advance. This
feature of RESTful architecture is known as HATEOAS
(Hypermedia As The Engine Of Application State) [4].
2 GAP IN RESTFUL ARCHITECTURE
Although there are several great positives of RESTful
architecture, strict adherence to RESTful architecture may
not be feasible all the time. Several online tools have been
flexible with the architecture and some have even
altogether moved to a novel architecture. A classic example
would be Facebook moving away from RESTful architecture
to a Graph architecture 2 [5]. Yahoo also uses a query
language (YQL)3 for delivering its services. Although it has a
REST based API for social data, the API does not completely
adhere to RESTful architectural principals.
1 Gopi Krishna Suvanam, is the Co-Founder and Director, of G-Square Solutions Pvt. Ltd. E-mail: gopi@g-square.in.
2 The Next Evolution of Facebook Platform, https://developers.facebook.com/blog/post/377/
3 Introducing YQL, https://developer.yahoo.com/yql/guide/overview.html
This tweaking of RESTful architecture is because of an
inherent gap in the architecture. RESTful architecture has
developed in conjunction with the development of world-
wide web (WWW) and http protocol. This architecture has
been developed to mimic World Wide Web [6]. Simplicity,
visibility and scalability of modern web has inspired this.
WWW itself was developed to serve static documents,
although over time it has become a much richer platform.
Nevertheless the congenital bias towards documents is still
embedded in RESTful architecture. To sum up Roy Fielding –
“The key abstraction of information in REST is a resource.
Any information that can be named can be a resource: a
document or image, a temporal service (e.g. “today’s
weather in Los Angeles”), a collection of other resources, a
non-virtual object (e.g. a person), and so on” [7]. Resource-
representation architecture has a fundamental drawback for
certain type of applications. As every piece of information in
this architecture has to be modelled as a resource certain
information is not easy to represent. For example if we want
to find out weather at let’s say Los Angeles (34.05° N,
118.25° W) we could use a URI like /weather/LA or
/weather/35.05/118.25. But if we want to fine tune it and
find out weather of a particular locality in LA we will be
forced
to
make
the
URI
something
like
/weather/35.050456/118.25090. Thus the number of URIs
can theoretically be infinite as the longitude and latitude are
continuous variables. There could be practical work around
for using a RESTful architecture even in such cases but they
fundamentally violate philosophy of RESTful representation.
As an example one could do:
Step 1: Post /mylocation
‘lat’=35.050456,’long’=118.25090
Step 2: Get /mylocation/weather But we believe this is in fact a hack and not in line with the core philosophy of de-coupled interactions. An easier architecture would be to express weather as a function and to obtain weather of a particular location one can simply call: get_weather(34. 050456, 118. 25090). This architecture draws inspiration from functional programmin
This content is AI-processed based on ArXiv data.