I think you are confusing discoverability with navigation. It's good if you can discover all content through hypermedia, but why should you prevent direct access?! It's like saying that there should be an indes in every book (yes!), and therefore you should not ever tell anyone on which page of the book they can find something relevant (wtf?).
> I think you are confusing discoverability with navigation.
I'm not. I understand why it's hard to swallow though, because I think a valid criticism of the REST architectural style is that it removes bookmark-ability.
> It's good if you can discover all content through hypermedia, but why should you prevent direct access?!
Well, precisely because direct access implies that out-of-band knowledge is driving the interaction rather than hypermedia. I would refer you to Fielding's discussion of the topic[0] where he notes:
> A REST API should be entered with no prior knowledge beyond the initial URI (bookmark) and set of standardized media types that are appropriate for the intended audience (i.e., expected to be understood by any client that might use the API). From that point on, all application state transitions must be driven by client selection of server-provided choices that are present in the received representations or implied by the user’s manipulation of those representations. The transitions may be determined (or limited by) the client’s knowledge of media types and resource communication mechanisms, both of which may be improved on-the-fly (e.g., code-on-demand).
> It's like saying that there should be an indes in every book (yes!), and therefore you should not ever tell anyone on which page of the book they can find something relevant (wtf?).
Interacting with a web service/site is not like interacting with a book (or a physical address), because there is no permanence as there is with physical objects. Have you never tried to go to an old bookmark to find that the content has been moved (and you get a nice 404)?
Anyway, I wasn't saying that this is all A Good Thing, just that the change in chrome doesn't seem at all at odds with REST (however, as many have pointed out, it can be at odds with usability)
Well, I am no priest of REST, but I think you are completely misinterpreting Mr. Fielding's point. That whole paragraph that you are quoting there is all about discoverability, at least that's how I interpret it. I mean, he even uses the word "bookmark", a concept which you seem to claim is incompatible with the approach. There is nothing in there that suggests you have to start at the one global canonical URI (which one would that even be? http://www.google.com/?), all it says is that whatever the initial URI is that you start at, the data you get back should be hyperlinked, using URIs, to any other resources that might be related to it, so that you can discover those related resources _without_ _prior_ _knowledge_ of _how_ _to_ _find_ _those_ _related_ _resources_, except through very general knowledge about the media type that the data is formatted as. Really, all that means is that a REST API that exposes a discussion thread and the postings in it, say, should not specify that for a given thread, the postings can be found as <thread-uri>/posting/<number> (because that would be out-of-band), but instead the document describing the thread should contain the URIs of the postings, so that general URI resolution mechanisms can be used to obtain them. In a way, it's all precisely about making things "bookmarkable", by using one common explicit addressing scheme for everything.
And that addresses can become dangling is completely besides the point. To solve that, you need a more stable addressing system instead of just not using addresses at all (which you really can't, if you think you can, you are confused and probably about to create an even less stable addressing system).
