Re: RESTful URLs?
--- In firstname.lastname@example.org, Aristotle Pagaltzis <pagaltzis@...> wrote:
> > It seems to me that in cases like this this there will have to
> > be a deterministic, programmatic method of producing URIs based
> > on some kind of template or documentation or something else.
> Exactly. But the template must be provided by the server in
> hypermedia, not hardwired into the client on a per-app basis.
This is where I get a little bit stuck when I think about the hypermedia constraint of REST. At some point it seems that a transition needs to be made between the world of machine-discovered application interaction and the world of human-discovered application interaction. At some level there will be an agreement made between the server application writers and the client application writers that tells the client guys what they need to hardcode into their apps. That is, which aspects of the interface are guaranteed to never change.
One option for doing this is a documented URI schema. In REST, this is considered bad because clients should be interacting with hypermedia, not constructing URIs based on promises from the server.
The other option (the one prescribed by REST) is hypermedia. OK, so you return a set of hyperlinks or some kind of form to the client. The use of well-known hyperlink tags and standard form vocabularies provides a higher level of machine-discoverable semantics. For example, my app knows itâs safe to do a GET on a hyperlink. And it knows that, say, the form is asking for an input selection of one of the following 3 choices. But what does this really mean? How does my application distinguish between one hyperlink and another hyperlink? The one tagged âparentsâ probably returns the current resourceâs parent resources and the one tagged âchildrenâ returns its children. But arenât we back to hardcoding knowledge into the application about what âparentsâ and âchildrenâ actually mean? If the server ever changes this meaning, my application breaks. The same goes for content (as opposed to the structure) of the forms.
I think that the answer comes down to well-known representation formats. The semantics hardcoded into client application should be based on metadata that is not determined by the server but rather by an agreed upon, standardized format that is guaranteed to never change. As long as the server implements the format correctly, everybody is automatically in agreement. But â" taking forms as a specific example -- there still seems to be missing information. The form structure may be standardized, but the semantics associated with the content of a specific form instance will be specialized for each application. Arenât we back, then, to hard-coding semantics into the client based on documentation from the server?
In this case, how much difference is there between documenting the semantics of a transparent URI schema or documenting the semantics of a specific form instance (assuming the form is used to drive a program).
Iâm not trying to be argumentative here... the hypermedia constraint of REST is something that Iâm finding the most difficult of all the core principles to understand in practical terms. Iâm very interested in your take on this topic.
- 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