Hot as HATEOAS: Why We Built A HATEOAS Server From Scratch

What is HATEOAS, why should you care (and how do you pronounce it)?

Technically, “hey-dee-us” is a constraint of Level 3 REST application architecture. An acronym for Hypermedia as the Engine of Application State, HATEOAS allows a client to interact with a network application through "hypermedia" (essentially, links) which makes it easier to develop commerce experiences (for Web and devices).

Developers in charge of turning an organization's business requirements into functioning applications have a choice of technologies to work with. Level 3 REST makes life easier as the "client" (the application or system the developer is building) doesn't need prior knowledge on how to interact with a server or other application other than following links and using simple controls such as GET or DELETE.

Say the application needs to connect to product information, images, price tables, product reviews and a customer's order history. This data may exist in many different places - different databases and tables, internal systems and potentially 3rd party cloud systems. Traditionally, you'd need to know the programming languages or "schema" of each of these data sources. The schema would have a product table, a description table, an image table, another system for prices, etc. You would have to know how to "call" each service to access the data, how to join everything together based on IDs, how to construct a SQL query, etc. This takes a lot of expensive knowledge, developers with advanced skills are needed to make it happen. Another way is with SOAP calls, which is not much easier. Typically, these would be made using remote procedure calls (RPC), SOAP or simple REST APIs.

With Level 3 REST, to populate a product page, the application just needs to know the initial product document and follow links to get prices, pictures, description and any other required data.

This can be compared to the old school way of doing research through libraries. You used to need to know where the library's card catalog was, know the Dewey Decimal system, look up the record, find the card, match the card to the item on the shelf, and check out through a librarian's desk. Today, you use a search engine, click a link, and keep following links within these documents to original sources, more information, related articles, author bios, multimedia, and so on.

So here's how HATEOAS fits in to REST, in a nutshell. It's a design principle which states that clients should only interact with network applications using basic, generic hypermedia controls. Neither the client software, and its developer, require specialized knowledge about how to interface with the server beyond a URL and a general understanding of hypertext protocols such as http. HATEOAS improves the flexibility, security, and scalability of REST as an application architecture.

The commerce potential for this API is huge. We are living in a multi-touchpoint, post-PC world. The industry has become very good at serving online stores through web browsers that rival the physical world shopping experience. But that's pretty much the end of the road in terms of innovation.

People aren’t engaging with just the desktop anymore. It's all turned into pieces of glass - smartphones, tablets, gaming consoles and even Google Goggles offer plenty of ways to connect to the digital space from the physical world. There are many online interactions that support commerce activity that don't end in an immediate sale, like research/browsing, interactions with a branded apps, local marketing response, and the like. We want to capture and provide a channel for capturing the in-between activities and add more value to the intellectual experience of your customer.

For example, imagine enabling telecom customers to load up services or manage their account by voice command through a smartphone app, bypassing a web interface entirely. Or, a cosmetics retailer making color and product suggestions based on a self-portrait taken with a smartphone. Picture creating a shopping list and ordering groceries online by snapping photos of empty food containers or scanning their barcodes. All these experiences require connecting to various commerce systems, which can be achieved faster and cheaper with Level 3 REST architecture.

Here at Elastic Path, we've built our own HATEOAS server to transform our complex ecommerce application into an API that can be used to create innovative experiences with little or no training. Our Level 3 REST API doesn't simply use links, but also attaches types behind it - semantic labels that humans can understand (the first of its kind). Sr. Product Architect Matt Bishop spoke on how we accomplished this at REST Fest, video below.

https://vimeo.com/49609648