On Apr 26, 2009, at 10:38 AM, Bill Burke wrote:
> So the "application" in Engine of Application State is really your
> browser. Links provide a way to change the state of your browser.
> Forms provide a way to change the state of your resource.
>
Most of the time, with some caveats:
The "application" is what the user is trying to accomplish,
such as "buy a book" or "transfer money from one account
to another" or "watch some monty python episode". The browser
is just the software that presents and operates upon the
application state.
Forms usually change the state of the browser as well.
Links and forms are specific UI mechanisms in HTML that teach
the browser how to construct the request upon activation.
A more elaborate media type could have more elaborate
mechanisms, and non-browser clients are even less restricted
in how they interact with media.
Although GET requests are not requesting a state change, it is
still possible for some resource states to change in response
to a GET. For example, there may be some other resource that
counts the number of GETs, or the most recent user agent.
When thinking about the Web (browsers) and Roy's thesis, do links and linkability really represent what HATEOAS is? I don't think so. Links aggregate...
... The answer is right there in your own words. "Application state" != "resource state" So, the HTML page in your browser has a bunch of ordinary <a> links in...
I find it useful to view application state as the sum of client state and those parts of resource the client cares about. In other words: The intersection of...
... So the "application" in Engine of Application State is really your browser. Links provide a way to change the state of your browser. Forms provide a way...
No the application is the site/webapp/whatever ... The idea being to tell the client what to do next in the application via Hypermedia instead of previously...
Still, I think an HTML form is an excellent illustration of HATEOAS on the Web. It is a self-describing *interaction* between the client and server where a...
Right... The hypertext constraint specifies that potential "workflows" are captured through linking or other hypermedia descriptors. Roy Fielding called the...
... To make things a bit clearer, forms are simply links with a UI attached to help people write the links, nothing more. They are just links. I can search...
I do agree that <forms> fundamentally serve the role of fulfilling HATEOAS. However, I disagree that they are "simply links with UI attached." I'd put it a...
... Forms are just another media type. An HTML form is *exactly* the same as XML. In XML your media type is "application/xml" and your template is XSD. For...
... The browser, or any other user-agent, holds a "representation" of a resource, and as so a specific state of a application, taken as the functionality...
... So the "application" in Engine of Application State is really your browser. Links provide a way to change the state of your browser. Forms provide a way...
... Most of the time, with some caveats: The "application" is what the user is trying to accomplish, such as "buy a book" or "transfer money from one account ...
I grok what you're saying, but I've always thought of Application as the overall set of states provided by the server (or set of interlinked servers), rather...
... Ideally, why would a server provide* a state that is not part of what the user is trying to achieve? imho, I think this definitions game would just end us...
There are different types of clients for a given server. Each client may use a slice of the overall set of states. For example, admin vs. end user, or User...
... I think these would be 2 different applications. As Roy, said "Application is what the user is trying to accomplish". Now I know , we can argue that this...
Having problems with message search?
Fill out this form to ensure your group is one of the first to be migrated to the new message search system.
Offline 
Send Email