Using Hypermedia Constraint API to drive UI

Question

I want to use a REST API with hypermedia constraint to drive my UI. That is, depending on "possible next states" for the resources I fetch, I want to adapt my UI for this. I'm quite new to UI dev on the web so I wonder if there is any special considerations I need to care about here?

Lets say I have a resource that looks like this:

{
   href: "..",
   orderDate: date..,
   details: {
       href : "..",
       items: [..],
   }  
   links: [
   placeOrder : {
        href : "...",
        method : "post"
   },
   cancelOrder : {
        href : "...",
        method : "delete"
   }]
}

Would the above links approach be valid within the context of HATEOAS ? In a perfect world I guess one should just know about HTTP verbs for actions on the resource but if I want to let the UI know about what can be done to the resource, how do I do this in an idiomatic way?

What I mean is, the same kind of resource can have different "next possible state" depending on current status. And the UI needs to know about this. Should the UI examine what links are available on the resource or how do I do this?

score 2 · Answer 1 · answered Nov 16 '13 at 20:44

Yes, exactly. The UI should be coded entirely to the link relations presented to it. If a relation isn't available to follow, it shouldn't be returned in the link collection in the response. That drives not only current state, but also means that the UI isn't burdened with trying to calculate access control rules.

score 0 · Answer 2 · answered Dec 07 '18 at 11:39

If by idiomatic you mean systematic then the description of the processing rules for the JSON you return need defining, then you communicate your cool new media-type via the Content-Type header.

https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

A REST API should spend almost all of its descriptive effort in defining the media type(s) used for representing resources and driving application state, or in defining extended relation names and/or hypertext-enabled mark-up for existing standard media types. Any effort spent describing what methods to use on what URIs of interest should be entirely defined within the scope of the processing rules for a media type (and, in most cases, already defined by existing media types). [Failure here implies that out-of-band information is driving interaction instead of hypertext.]

He's saying to put all your effort into figuring out how to design a data format and its rules such that the system is fully expressive for all its needs, like HTML.

(Or skip this and just use HTML for your API).

Using Hypermedia Constraint API to drive UI

2 Answers2