Note that there are some explanatory texts on larger screens.

plurals
  1. POSplitting hairs with REST: Does a standard JSON REST API violate HATEOAS?
    primarykey
    data
    text
    <p>I was doing some reading on REST this morning and I came across the <a href="http://en.wikipedia.org/wiki/HATEOAS">HATEOAS principle ("hypermedia as the engine of application state")</a>.</p> <p>Quoting the <a href="http://en.wikipedia.org/wiki/Representational_state_transfer">REST Wikipedia page</a>:</p> <blockquote> <p>Clients make state transitions only through actions that are dynamically identified within hypermedia by the server (e.g. by hyperlinks within hypertext). Except for simple fixed entry points to the application, a client does not assume that any particular actions will be available for any particular resources beyond those described in representations previously received from the server.</p> </blockquote> <p>And <a href="http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven">Roy Fielding's blog</a>:</p> <blockquote> <p>...if the engine of application state (and hence the API) is not being driven by hypertext, then it cannot be RESTful and cannot be a REST API. Period. </p> </blockquote> <p>I read this as: The client may only request state changes based on the actions made available from the body of the response from the server (the hypertext).</p> <p>In an HTML world, this makes perfect sense. The client should only be able to request state changes (new actions/pages) based on the links made available to them through the hypertext (HTML).</p> <p>When the resource is represented in other ways - such as JSON, XML, YAML etc. This is not so apparent.</p> <p>Let's take an example "REST" JSON API:</p> <p>I create a new resource (a new comment for example) by sending a POST request to</p> <p><code>/comments.json? # with params...</code></p> <p>The server responds with:</p> <pre><code># Headers HTTP/1.1 201 Created Location: http://example.com/comments/3 Content-Type: application/json; charset=utf-8 ... Etc. # Body {"id":3,"name":"Bodacious","body":"An awesome comment","post_id":"1"} </code></pre> <p>I know that I can now access this comment at the URI returned in the header: <a href="http://example.com/comments/3.json">http://example.com/comments/3.json</a></p> <p>When I visit <a href="http://example.com/comments/3.json">http://example.com/comments/3.json</a> I see:</p> <pre><code>{"id":3,"name":"Bodacious","body":"An awesome comment","post_id":"1"} </code></pre> <p>Suppose the API's documentation tells me that I can delete this comment by sending a DELETE request to the same URI. This is fairly common amongst "REST" APIs.</p> <h2>However:</h2> <p>The response from the server at <code>GET http://example.com/comments/3.json</code> doesn't tell me anything about being able to delete the comment by sending a DELETE request. All it shows me is the resource. </p> <p>That I can also DELETE a comment with the same URL is something the client knows through out-of-band information (the documentation) and is not discovered and driven by the response from the server.</p> <p>Here, the client <strong>is</strong> assuming that the DELETE action (and possible others) are available for this resource and this information has not been previously received from the server.</p> <p>Have I misunderstood HATEOAS or am I right in saying than an API matching the above description would not, in the strict sense, be a REST API?</p> <p>I'm aware 100% adherence to REST is not always possible or the most pragmatic way to go. I've posted this question purely to satisfy my own curiosity about the theory behind REST, not for advice on real world best-practice.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

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