Re: [rest-discuss] Re: RESTful URLs?
- On Fri, Feb 6, 2009 at 12:54 AM, Roy T. Fielding <fielding@...> wrote:
> On Feb 5, 2009, at 5:45 PM, Bill de hOra wrote:
> > Assaf Arkin wrote:
> >> On the other hand, in my experience it's easier to build code
> >> around a
> >> fixed URL structure, and if you only imagine having one (or few)
> >> clients
> >> to a single service, hypermedia might be an overkill.
> > Also, hypertext for simple case tends to need two calls, one the
> > bootstrap document to find the link, and two, to the actual link you
> > care about. Whereas a fixed url scheme on the client means one call.
> Yes, a RESTful system is at least one level of indirection away
> from a strongly coupled system. A fixed URL scheme is essentially
> the same as baking the first representation into each client.
> Is that surprising?
> Likewise, a RESTful system is always going to be less efficient
> than a system designed for a static set of clients accessing
> a small set of services that never change.
> A lot of people think of systems as static things. Dead things.
> REST is not going to appeal to those people. All of its constraints
> are designed to keep systems living longer than we are willing
> or able to anticipate.
Roy, thanks for responding. I completely agree that way REST dynamically provides the next relevant set of URIs via HATEOAS is highly dynamic, and dynamic systems live longer than non-dynamic ones.But you didn't address the (apparent) tension between bookmarking/deep-linking and REST, which was my original question. Bookmarking takes a dynamically generated bookmark and effectively makes it static -- at least it's static (persisted) on the client side. As more and more clients bookmark more and more of the URIs they receive, the more they are incrementally "fixing" the original URI space.Hence my point: encouraging promiscuous bookmarking of (deep) links seems to be at odds with REST's desire to minimize "entry point" URIs. Do you see the tension as well, or am I missing something that resolves the tension?Devdatta makes the excellent point earlier in the thread about "I think it's a pretty major change in Web architectural thinking (or at least emphasis) to now say (effectively) that a significant class of URIs should NOT be cool, ie one should NOT expect them to be useable indefinitely. In a way, this harks all the way back to Parnas's admonition that we hide information that is likely to change. Using modern web-speak, REST seems to admonish us to "hide" the URIs that are likely to change (unCool URIs) and "expose" only those URIs that are likely to stay the same (Cool URIs). But nothing I've seen in the desciptions of Web Architecture (eg AWWWv1) remotely suggests that some URIs should effectively be hidden, or per my previous point, not bookmarked. If anything, Web Architecture descriptions at least imply that all URIs SHOULD be "exposed" and bookmarkable.Any light you can shed on this issue would be sincerely appreciated.-- Nick
- One of this things I find I often confront is the "dis-comfort" folks
experience when they identify the "inefficiency of abstraction" that
is the result of the loose coupling in the REST style.
I usually address this comfort the same way I address the "premature
On Sat, Feb 7, 2009 at 07:54, Bill de hOra <bill@...> wrote:
> Roy T. Fielding wrote:
>> On Feb 5, 2009, at 5:45 PM, Bill de hOra wrote:
>> > Also, hypertext for simple case tends to need two calls, one the
>> > bootstrap document to find the link, and two, to the actual link you
>> > care about. Whereas a fixed url scheme on the client means one call.
>> Yes, a RESTful system is at least one level of indirection away
>> from a strongly coupled system. A fixed URL scheme is essentially
>> the same as baking the first representation into each client.
> Right. I think some people, when thinking about bootstrap problems
> (which is what we're talking about here), end up in logical knots and
> fallacies, or worse, invent pointless discovery technologies to solve a
> non-problem. The first link is always out of band, get over it.
>> Is that surprising?
> Obviously not, but it seemed fair to point it out.
> Yahoo! Groups Links