Re: [rest-discuss] Which URIs are bookmarkable?
- On Tue, Oct 11, 2011 at 11:18 AM, Jan Algermissen
>Right, this is actually one of my issues with Atom because, in my
> On Oct 11, 2011, at 12:07 PM, Mike Kelly wrote:
>> On Tue, Oct 11, 2011 at 10:42 AM, Jan Algermissen
>> <jan.algermissen@...> wrote:
>>> On Oct 11, 2011, at 11:23 AM, Mike Kelly wrote:
>>>> A given application should specify its entry points explicitly
>>> This cannot work because the application only comes into existence based on the choices the client makes.
>> Do you mean application state?
>> Either way, not sure I understand your point; AtomPub is an
>> application, and it exists.
> No, AtomPub is a media type that enables a certain set of applications.
opinion, there should be complete separation between the media type
and the 'application' i.e. hal (media type) and a set of link
relations (the application).
>That's just a client performing multiple "applications" (I believe the
>The AtomPub spec suggests a set of canonical applications. But there are certainly many, many others. For example, crawling a dozen of feeds and building an index of posts is one that is not in the AtomPub spec.
Jian™ terminology for this is Domain Application Protocol™) in a
particular sequence. Yes, there's some unique application state stuff
involved on the client side but that's not related to the AtomPub
application/DAP I was referring to originally and, more to the point,
isn't actually visible to the network. If you create a user agent that
generates and manages some application state of its own that's great
but I don't see what that has to do with bookmark-ability of the
resources or the Domain Application Protocols™ it's engaging in. The
DAPs are what is informing your user-agent of the significance of
given resources, and that is where (if at all) any potential entry
points should be specified.
On Tue, Oct 11, 2011 at 9:40 AM, Jan Algermissen <jan.algermissen@...> wrote:--
[...] In general, I am trying to answer the question:
What are the indicators in media type (and link relation) specifications that tell
the user agent implementor what URIs in responses of the media type in question
can be considered bookmarkable?Isn't it the prose in the media type specification itself? A media type indicates that activating a particular hypermedia control advances the user agent to a new application state. If that ends up in a "safe" state (i.e. it ends up with a GET'able resource) then that means that it's a "bookmarkable state" and one that's worthy of a future entry point.Example: if a form directs you to POST something to a URI and it responds with a redirect to another resource, and the agent automatically follows that cue, then that new resource would IMHO be a bookmarkable state.HTML states this clearly for <A>: "By activating these links [...], users may visit these resources." . For <IMG> images are to be "embedded [...] in the current document" .
- On Oct 11, 2011, at 9:40 AM, Jan Algermissen wrote:
> Hi,HA! It has been in the archives all along (thanks, Roy :-)
> how do I decide whether a URI is bookmarkable or not?
"If the application is
designed correctly, then the only times that the user agent
will pause long enough to make a bookmark will be at one of
the application steady states, which should correspond to one
of the cool URIs. In other words, a RESTful architecture will
expose the cool URIs (and only the cool URIs) to the user."
> ('Bookmarkable' meaning: 'Being an entry point into an application that is worth remembering')
> Some things to consider:
> There is a difference between the stability of a URI (whether a client can asssume a URI will
> be dereferencable in the future) and the suitability of a URI to act as an application entry point.
> For example, I'd assume HTML style sheet URIs to be pretty stable but they are not useful
> application entry points.
> Should a user agent remember as many URIs as possible, thereby increasing the amount of
> known application entry points and possibly avoiding re-doing certai steps through the
> application in the future (sth we do all the time when bookmarking e.g. page 4 of
> a search result).
> o All URIs I find in responses from a server in a link context are bookmarkable
> ('Link context' meaning Atom <link> elemnts, HTML <a> elements, Link headers,
> HTML GET-forms, etc.)
> o Not all URIs I find in responses from a server are bookmarkable. For example,
> - a URI I find in an HTML <form> element with action 'POST' is not
> - a URI I find in an Opensearch <Url> element is not
> - a URI I find in an HTML <style> element is not
> o What about
> - a URI I find in an HTML <img> element
> - a URI I find in an AtomPub <collection> element
> - a URI I find in HTTP headers such as Location, Content-Location, Alternates
> - AtomPub's edit-media links?
> - Atom <content src=""> references
> Does the cachability of a response affect these issues?
> In general, I am trying to answer the question:
> What are the indicators in media type (and link relation) specifications that tell
> the user agent implementor what URIs in responses of the media type in question
> can be considered bookmarkable?