ATPHIZYOM Artificial Intelligence & REST-Architecture

The ATPHIZYOM Mobile & Web Application (“App”) is built on an API layer (Application Programming Interface) based on REST-Architecture that allows streamlined-accessing of all historical Asset stochastic data for input into and analysis by the ATPHIZYOM System AI (Artificial Intelligence model) and ATOM-Algorithm. “Real-Time” User requests (initiated from the App-interface) carrying all the necessary User Information for the server to complete the requests are sent to the ATPHIZYOM Cloud-based Data Storage & Analytics Center for processing. The User-generated request is then processed and analyzed by the ATPHIZYOM System AI [A.D.A.M.] via the Cloud-based ATOM-Algorithm in real-time, and the subsequent User query result output transferred instantaneously back to the User’s App-interface for display.

Representational State Transfer [REST] is an architectural style that defines a set of constraints and properties based on HTTP. Web Services that conform to the REST architectural style, or RESTful web services, provide interoperability between computer systems on the Internet. REST-compliant web services allow the requesting systems to access and manipulate textual representations of web resources by using a uniform and predefined set of “stateless” operations. By using a stateless protocol and standard operations, REST systems aim for fast performance, reliability, and the ability to grow, by re-using components that can be managed and updated without affecting the system as a whole, even while it is running. Hence, the merits of such an implementation by constructing the overall ATPHIZYOM Mobile & Web Application via an underlying REST-Architecture at its core and integrating the ATPHIZYOM System AI [A.D.A.M.] with its embedded architecture are:

• Performance: User-perceived [CLIENT] Network Performance & Efficiency seamlessly delivered by The Host [ATPHIZYOM]
• Scalability: User-driven [CLIENT] Product/Service Scale & Extensive Scope effectively executed & managed by The Host [ATPHIZYOM]
• Maintenance: Simplicity of a Uniform Interface, Modifiability, Portability, Visibility of Components by Service Agents [ATPHIZYOM]
• Reliability: Resistance to Failure at the System Level [ATPHIZYOM] in presence of failures within Components, Connectors or Data

What is REST?
[Ref: Dr. M. Elkstein (2008). Learn REST: A Tutorial. World Wide Web: http://rest.elkstein.org/]

REST stands for Representational State Transfer. (It is sometimes spelled “ReST”.) It relies on a stateless, client-server, cacheable communications protocol — and in virtually all cases, the HTTP protocol is used.

REST is an architecture style for designing networked applications. The idea is that, rather than using complex mechanisms such as CORBA (Common Object Request Broker Architecture), RPC (Remote Procedure Call) or SOAP (Simple Object Access Protocol) to connect between machines, simple HTTP is used to make calls between machines. In many ways, the World Wide Web itself, based on HTTP, can be viewed as a REST-based architecture.

RESTful applications use HTTP requests to post data (create and/or update), read data (e.g., make queries), and delete data. Thus, REST uses HTTP for all four CRUD (Create/Read/Update/Delete) operations.

As a programming approach, REST is a lightweight alternative to mechanisms like RPC (Remote Procedure Calls) and Web Services (SOAP – Simple Object Access Protocol, WSDL – Web Services Description Language, et al.). REST is simple and yet fully-featured; there’s basically nothing you can do in Web Services that can’t be done with a RESTful architecture. REST is not a “standard”; there will never be a W3C recommendation for REST, for example. And while there are REST programming frameworks, working with REST is so simple that you can often “roll your own” with standard library features in languages like Perl, Java, or C#.

Much like Web Services, a REST service is:

• Platform-independent (independent of whether the server is Unix-based, the client is Mac/PC-based, or any other Platform/OS formats, etc.)
• Language-independent (C# can communicate/exchange with Java, etc.)
• Standards-based (runs on top of HTTP)
• Can easily be used in the presence of firewalls

Like Web Services, REST offers no built-in Security Features, Encryption, Session Management, QoS (Quality of Service) Guarantees, etc. But also as with Web Services, these can be added by building on top of HTTP:

• For Security, Username/Password Tokens are often used.
• For Encryption, REST can be used on top of HTTPS (Secure Sockets).
• … etc.

The “ST” in “REST” stands for “State Transfer”, and indeed, in a good REST design operations are self-contained, and each request carries with it (transfers) all the information (state) that the server needs in order to complete it.