Comments on: Explaining State in HATEOAS http://www.subbu.org/blog/2008/10/explaining-state-in-hateoas HTTP, REST and some Cycling Mon, 15 Mar 2010 08:14:09 +0000 http://wordpress.org/?v=2.8.4 hourly 1 By: William Vambenepe — REST in practice for IT and Cloud management (part 3: wrap-up) http://www.subbu.org/blog/2008/10/explaining-state-in-hateoas/comment-page-1#comment-47527 William Vambenepe — REST in practice for IT and Cloud management (part 3: wrap-up) Thu, 10 Dec 2009 10:16:52 +0000 http://www.subbu.org/?p=503#comment-47527 [...] media types to describe interfaces to those transitions.” I get the hypermedia concept, the HATEOAS approach and its very practical benefits. But I am still dubious about the role of Mime types in achieving [...] [...] media types to describe interfaces to those transitions.” I get the hypermedia concept, the HATEOAS approach and its very practical benefits. But I am still dubious about the role of Mime types in achieving [...]

]]> By: Shantanu Kumar http://www.subbu.org/blog/2008/10/explaining-state-in-hateoas/comment-page-1#comment-37165 Shantanu Kumar Fri, 21 Aug 2009 16:54:05 +0000 http://www.subbu.org/?p=503#comment-37165 @Bill, @Subbu I am wondering how about embedding only the URI of a resource (rather than its representation) into the referring resource representation. This may lead to additional round-trip (fortunately GET can be cached), but it will let you avoid "stateful-ness" of the resource by the introduced level of indirection. @Bill, @Subbu

I am wondering how about embedding only the URI of a resource (rather than its representation) into the referring resource representation.

This may lead to additional round-trip (fortunately GET can be cached), but it will let you avoid “stateful-ness” of the resource by the introduced level of indirection.

]]> By: vano http://www.subbu.org/blog/2008/10/explaining-state-in-hateoas/comment-page-1#comment-14784 vano Wed, 24 Dec 2008 14:56:01 +0000 http://www.subbu.org/?p=503#comment-14784 IMO, the topic of "state" is very important. Would be nice if you could write another post "Explaining State in REST" (here I mean the third letter "S" in the acronym) and comparing it with the State in HATEOS. IMO, the topic of “state” is very important. Would be nice if you could write another post “Explaining State in REST” (here I mean the third letter “S” in the acronym) and comparing it with the State in HATEOS.

]]> By: Subbu Allamaraju http://www.subbu.org/blog/2008/10/explaining-state-in-hateoas/comment-page-1#comment-8709 Subbu Allamaraju Wed, 29 Oct 2008 03:34:36 +0000 http://www.subbu.org/?p=503#comment-8709 Other than by putting the cart in some kind of a database? Other than by putting the cart in some kind of a database?

]]> By: Stephan Schmidt http://www.subbu.org/blog/2008/10/explaining-state-in-hateoas/comment-page-1#comment-8688 Stephan Schmidt Tue, 28 Oct 2008 21:12:53 +0000 http://www.subbu.org/?p=503#comment-8688 Cart ;-) Cart ;-)

]]> By: Stephan Schmidt http://www.subbu.org/blog/2008/10/explaining-state-in-hateoas/comment-page-1#comment-8687 Stephan Schmidt Tue, 28 Oct 2008 21:12:22 +0000 http://www.subbu.org/?p=503#comment-8687 .... and how do we represent a shopping card then? http://stephan.reposita.org/archives/2008/10/09/the-future-web-development-without-web-frameworks-my-slides-from-the-first-berlin-java-conference/ Peace -stephan …. and how do we represent a shopping card then?

http://stephan.reposita.org/archives/2008/10/09/the-future-web-development-without-web-frameworks-my-slides-from-the-first-berlin-java-conference/

Peace
-stephan

]]> By: subbu http://www.subbu.org/blog/2008/10/explaining-state-in-hateoas/comment-page-1#comment-8515 subbu Mon, 27 Oct 2008 02:39:39 +0000 http://www.subbu.org/?p=503#comment-8515 I don't want to say that this is "poisoning developer minds", but explaining that representations are akin to some value objects is a bit misleading. Here is why. Let me consider a bank transfer example, where we identified a bank transfer as a resource. The usual flow is as follows: POST /transfer -----> 201 Created, Location: http://example.org/transfer/1 Now, when a client submits a "GET /transfer/1", what should the server return? In the value object model, it would return some serialized form of that object, e.g., as in <transfer> <id>urn:example:transfer:1</id> <link rel="src" href="..."/> <link rel="target" href="..."/> <amount>100</amount> </transfer> But this does not tell me anything about the "state of the application" viz., the "state of the interactions between the server and this client". The state of the application could be that the transfer is pending, and the client will need to check some other link to get the status of the transfer. This could be represented by including a link to that status resource in the above representation. At the end, we have links, but IMO, what they are meant to represent is a key point. Consider a different example. A client is submitting a POST to create a new customer resource. Due to some peculiar implementation details, the server wants the user to verify this process by submitting a one-time verification link. 201 Created Location: http://blah <customer> ... <link rel="verify" href="http://blah?adasd312da"/> </customer> The link here indicates the state of the application, i.e, the process is not done, and the user needs to activate the link with relation "verify". To sum up, representations contain both the (persistent) state of the resource as well as the state of the application (i.e., the interactions). I don’t want to say that this is “poisoning developer minds”, but explaining that representations are akin to some value objects is a bit misleading. Here is why.

Let me consider a bank transfer example, where we identified a bank transfer as a resource. The usual flow is as follows:

POST /transfer —–> 201 Created, Location: http://example.org/transfer/1

Now, when a client submits a “GET /transfer/1″, what should the server return? In the value object model, it would return some serialized form of that object, e.g., as in

<transfer>
<id>urn:example:transfer:1</id>
<link rel=”src” href=”…”/>
<link rel=”target” href=”…”/>
<amount>100</amount>
</transfer>

But this does not tell me anything about the “state of the application” viz., the “state of the interactions between the server and this client”. The state of the application could be that the transfer is pending, and the client will need to check some other link to get the status of the transfer. This could be represented by including a link to that status resource in the above representation. At the end, we have links, but IMO, what they are meant to represent is a key point.

Consider a different example. A client is submitting a POST to create a new customer resource. Due to some peculiar implementation details, the server wants the user to verify this process by submitting a one-time verification link.

201 Created
Location: http://blah

<customer>
…
<link rel=”verify” href=”http://blah?adasd312da”/>
</customer>

The link here indicates the state of the application, i.e, the process is not done, and the user needs to activate the link with relation “verify”.

To sum up, representations contain both the (persistent) state of the resource as well as the state of the application (i.e., the interactions).

]]> By: Bill Burke http://www.subbu.org/blog/2008/10/explaining-state-in-hateoas/comment-page-1#comment-7952 Bill Burke Thu, 23 Oct 2008 21:14:36 +0000 http://www.subbu.org/?p=503#comment-7952 Although using the common example of HTML passed back with a FORM in it to describe HATEOAS is a good start, I find that it leaves people still scratching their heads. Its like trying to convince somebody Number theory is so cool by stating "1 + 1 = 2!" Its just too obvious its invisible. I've explained HATEOAS with this analogy to Java developers. Imagine, a Java Swing app passing value objects to a remote Hibernate service and merging the changes. Instead of Java objects are your value objects, think of XML or JSON. Now add the idea of embedding links into your XML or JSON that tell you where you can edit the service that represents these value objects, or links to other services related to this data. Maybe I'm poisoning developer minds with impure thoughts, I don't know... :) Although using the common example of HTML passed back with a FORM in it to describe HATEOAS is a good start, I find that it leaves people still scratching their heads. Its like trying to convince somebody Number theory is so cool by stating “1 + 1 = 2!” Its just too obvious its invisible.

I’ve explained HATEOAS with this analogy to Java developers. Imagine, a Java Swing app passing value objects to a remote Hibernate service and merging the changes. Instead of Java objects are your value objects, think of XML or JSON. Now add the idea of embedding links into your XML or JSON that tell you where you can edit the service that represents these value objects, or links to other services related to this data.

Maybe I’m poisoning developer minds with impure thoughts, I don’t know… :)

]]> By: Keith Gaughan http://www.subbu.org/blog/2008/10/explaining-state-in-hateoas/comment-page-1#comment-7744 Keith Gaughan Wed, 22 Oct 2008 22:51:22 +0000 http://www.subbu.org/?p=503#comment-7744 I think application state can be boiled down even further than that. The way I try to explain it is by saying that it's where you are and how you got there. Then I'd use an example of it at work in a regular website, but that first bit ("it's where you are and how you got there") is the critical thing to understand; the explanation just reifies it. I think application state can be boiled down even further than that. The way I try to explain it is by saying that it’s where you are and how you got there. Then I’d use an example of it at work in a regular website, but that first bit (”it’s where you are and how you got there”) is the critical thing to understand; the explanation just reifies it.

]]>