4481RE: [rest-discuss] Client-composed URI paths
- Jun 22, 2004We've been looking at this in the WSD WG. The WSDL 2.0 HTTP binding has a mechanism for specifying how a URI space is populated based upon schema and instance data. I've tried my hand at creating an example of the Artist showing how the HTTP binding would be used atI kind of think it sucks, it's too complicated and it doesn't seem to make the simple things simple, as I describe in the message.Also, there's some use of HTTP headers in REST, which we haven't formally done in the WSD until now. We've been working on a proposal for how to specify out-of-band, or Application Data, that is intended to be serialized as HTTP or SOAP headers. Myself and Glenn have responsibility for this in WSD, and we're almost there, but it's not quite ready.Cheers,Dave-----Original Message-----
From: Jeff Bone [mailto:jbone@...]
Sent: Tuesday, June 15, 2004 12:23 AM
Subject: Re: [rest-discuss] Client-composed URI paths
On Jun 14, 2004, at 5:55 PM, Neil Kandalgaonkar wrote:
> In HTML, aren't the vast majority of URIs just provided in links?
Yes - explicit ones. We're talking about having the servers specify
generation rules for whole classes of valid URI, not merely passing out
explicit lists of them.
> Do you mean forms? Because, of course, that's a good standard for
> transforming client data into the query section of a URI.
> So I think the question is: do we need another standard for clients
> to transform user data into the *path* section? In a way customized
> to each REST application?
Whether it's in the query or the path is somewhat orthogonal to the
desire to express URI generatively. The preference for having such a
mechanism that works both with path parts and query parts is driven
mostly by caching concerns, otherwise somewhat by a resource modeling
philosophy that says conceptual hierarchy in the model should be
expressed as such in URI.
Cf., w/ caveat that this is purely my own (and early, not recently
revisited) thoughts on this:
Also check out Mark Nottingham's related thoughts on a WSDL approach to
- << Previous post in topic