Databases
StackOverflow2013
Postsdbo
POHATEOAS Client Design
Body
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POHATEOAS Client Design
    text
    copied!<p>I have read a lot of discussions here on SO, watched <a href="http://oredev.org/oredev2010/2010/sessions/hypermedia-apis.html" rel="nofollow noreferrer">Jon Moore's presentation</a> (which explained a lot, btw) and read over Roy Fielding's blog post on HATEOAS but I still feel a little in the dark when it comes to client design.</p> <p><strong>API Question</strong></p> <p>For now, I'm simply returning xhtml with forms/anchors and definition lists to represent the resources. The following snippet details how I lay out forms/anchors/lists. </p> <pre><code># anchors &lt;li class='docs_url/#resourcename'&gt; &lt;a rel='self' href='resource location'&gt;&lt;/a&gt; &lt;/li&gt; # forms &lt;form action='action_url' method='whatever_method' class='???'&gt;&lt;/form&gt; # lists &lt;dl class='docs_url/#resourcename'&gt; &lt;dt&gt;property&lt;/dt&gt; &lt;dd&gt;value&lt;/dd&gt; &lt;/dl&gt; </code></pre> <p>My question is mainly for forms. In Jon's talk he documents form types such as (add_location_form) etc. and the required inputs for them. I don't have a lot of resources but I was thinking of abstract form types (add , delete, update, etc) and just note in the documentation that for (add, update) that you must send a valid representation of the target resource and with delete that you must send the identifier. </p> <p><strong><em>Question 1:</em></strong> With the notion of HATEOAS, shouldn't we really just make the client "discover" the form (by classing them add,delete,update etc) and just send back all the data we gave them? My real question here (not meant to be a discussion) is does this follow good practice? </p> <p><strong>Client Question</strong></p> <p>Following HATEOAS, with our actions on resources being discover-able, how does this effect client code (consumers of the api) and their ui. It sounds great that following these principals that the UI should only display actions that are available but how is that implemented?</p> <p>My current approach is parsing the response as xml and usin xpath to look for the actions which are known at the time of client development (documented form classes ie. add,delete,update) and display the ui controls if they are available.</p> <p><strong><em>Question 2:</em></strong> Am I wrong in my way of discovery? Or is this too much magic as far as the client is concerned ( knowing the form classes )? Wouldn't this assume that the client knows which actions are available for each resource ( which may be fine because it is sort of a reason for creating the client, right? ) and should the mapping of actions (form classes) to resources be documented, or just document the form classes and allow the client (and client developer) to research and discover them?</p> <p>I know I'm everywhere with this, but any insight is much appreciated. I'll mark answered a response that answers any of these two questions well. Thanks!</p>
 

Querying!

 
Guidance
An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload