REST Client Implementation Embracing HATEOAS Constraint?

Question

Does anybody know of an implementation of a REST client that embraces the constraint of Hypermedia as the Engine of Application State (HATEOAS)?

The Sun Cloud API seems to be a good candidate, judging from the way it's documented and a statement by the author to the effect that Ruby, Java, and Python implementations were in the works. But so far I've found no trace of the code.

I'm looking for anything - even a partial implementation would be helpful.

Answer 1

The HATEOAS design principle (REST is a set of design principles also) means that each resource should have at most a single fixed URL.

Everything else related should be discoverable dynamically from that URL through "hypermedia" links.

I just started a wikipedia stub here

Answer 2

Restfulie is a Ruby, Java, and C# framework which aims to enable building clients and servers which employ HATEOAS. I haven't used it, but it does look interesting.

Here's some example code from their java project:

Order order = new Order();

// place the order
order = service("http://www.caelum.com.br/order").post(order);

// cancels it
resource(order).getTransition("cancel").execute();

Again, I'm not sure exactly what this does, or how well it works in practice, but it does seem intriguing.

Answer 3

Rich,

I am working on a RESTful client side framework for Jersey right now. Once the initial design stabelizes a bit it will be added to the Jersey code base and after going through the community for review should eventually drive the shape of JAX-RS's client side framework.

There has been a lively discussion on the Jersey users list recently about all things RESTful. https://jersey.dev.java.net/servlets/SummarizeList?listName=users

It should be about two weeks from now for the code to go public the first time for people to experiment.

Jan

Answer 4

The problem with REST HTTP and HATEOAS is that there is no common approach to specifying links so it is hard to follow links since their structure might change from a service provider to another. Some would use <link href="..." /> others would use proprietary structure for of links ex. <book href="..." />. It is not like in HTML or atom were link are part of a standard defined.

A client can't know what a link is in your representation is it doesn't know your media type unless there is a standard or conventional representation of a link

Answer 5

The very first thing you should look at is the common web browser. It is the standard for a client that embraces HATEOAS (at least to some degree).

This is how Hypermedia works. It's so simple that it's almost painful:

1. you point your browser to http://pigs-are-cool.org/
2. the browser loads the HTML page, images, CSS and so on.
   • At this point, the application (your browsing experience) is at a specific URI.
   • The browser is showing the content of that URI
3. you see a link in the application
4. you click the link
5. the browser follows the link
   • at this point, the application is at a different URI
   • The browser is showing the content of the new URI

Now for a short explanation of how the two terms relate to the web browsing experience:

• Hypermedia = HTML pages with the embedded links
• Application state = What you're seeing in the browser at any point in time.

So HATEOAS actually describes what happens in a web browser when you go from web page to web page:

HTML pages with embedded links drive what you see in the browser at any point in time

The term HATEOAS is just an abstraction of this browsing experience.

Other examples of RESTful client applications include:

• RSS and Feed readers. They traverse links given to them by users
• Most AtomPub blog clients. They need merely a URI to a services document, and from there they find out where to upload images and blog posts, search and so on.
• Probably Google Gadgets (and similar), but they're merely browsers in a different skin.
• Web crawlers are also RESTful clients, but they're a niche market.

Some characteristics of RESTful client software:

• The client works with with any server, given that it is primed with some URI and the server responds with an expected result (e.g. for an atom blog client, an Atom services document).
• The client knows nothing about how the server designs its URIs other than what it can find out at runtime
• The client knows enough media types and link relations to understand what the server is saying (e.g. Atom or RSS)
• The client uses embedded links to find other resources; some automatically (like <img src=) some manually (like <a href=).

Very often they are driven by a user, and can correctly be termed "user agents", except for, say GoogleBot.