web - HATEOAS

HATEOAS, an abbreviation for Hypermedia as the Engine of Application State, is a constraint of the REST application architecture that distinguishes it from most other network application architectures. The principle is that a client interacts with a network application entirely through hypermedia provided dynamically by application servers. A REST client needs no prior knowledge about how to interact with any particular application or server beyond a generic understanding of hypermedia. In a service-oriented architecture (SOA), clients and servers interact through a fixed interface shared through documentation or an interface description language (IDL).

RESTful service can be described as well to be available for the client code-generation, RSDL (RESTful Service Description Language) using dynamic metadata collection to achieve this goal.

The HATEOAS constraint serves to decouple client and server in a way that allows the server to evolve functionality independently.

Details[edit]

A REST client enters a REST application through a simple fixed URL. All future actions the client may take are discovered within resource representations returned from the server. The media types used for these representations, and the link relations they may contain, are standardized. The client transitions through application states by selecting from the links within a representation or by manipulating the representation in other ways afforded by its media type. In this way, RESTful interaction is driven by hypermedia, rather than out-of-band information.^[1]

A client does not need to understand every media type and communication mechanism offered by the server and this understanding may be improved on the fly through "code-on-demand" provided to the client by the server.^[2]

Origins[edit]

The HATEOAS constraint is an essential part of the "uniform interface" feature of REST, as defined in Roy Fielding's doctoral dissertation.^[2] Fielding has further described the concept on his blog.^[1]

The purpose of some of the strictness of this and other REST constraints, Fielding explains, is "software design on the scale of decades: every detail is intended to promote software longevity and independent evolution. Many of the constraints are directly opposed to short-term efficiency. Unfortunately, people are fairly good at short-term design, and usually awful at long-term design".^[1]

References[edit]

1. ^ Jump up to:^a b c Fielding, Roy T. (20 Oct 2008). "REST APIs must be hypertext-driven". Retrieved 20 May 2010.
2. ^ Jump up to:^a b "Representational State Transfer (REST)"

출처 - http://en.wikipedia.org/wiki/HATEOAS

---

The point of HATEOAS is that you are getting links on other resources from responses on your requests. Difference, in comparison with URL Templates, is that the client knows, has hardwired, just few URLs (entry points), and the rest of URLs is getting from responses on the fly. It brings loose coupling between client and server and that's main benefit of HATEOAS. Working with HATEOAS is same as surfing on Web, you just click on a link that is included in last response (e.g. HTML page), then again, and again. Point is that you don't know all the URLs before you get first response on URL that you know, the entry point. Today, HATEOAS is not well adopted, unfortunately. Most of APIs are publishing URL templates, and that means tight coupling; so I think you cannot expect support from existing frameworks now, but it's not so hard to implement your own URL repository, on client, that will collect URLs from responses you get. share|improve this answer edited May 15 '13 at 16:47 answered Apr 12 '13 at 14:48 filip26 3961316

2   Ok i understand better the philosophy. But i think that the client side is the most difficult part of HATEOAS, the server side is more easy to make. Thx for your reply. –  Thomas Pons Apr 12 '13 at 15:48

출처 - http://stackoverflow.com/questions/15972843/where-can-i-find-a-practical-hateoas-javascript-client-example/15974431#15974431