Re: RE> Queries could be done with a layer of indirection

>>    http://foo.bar.com/myrdb?row=1
>>
>> and
>>
>>    http://foo.bar.com/mybook?search=hypermedia+url+i18n;easy=as+pie
>>
>> can, and, I believe, should, be treated differently. In the first case,
>> you have what is effectively a deterministic address, in the second
>> case you are dealing with user input.
>
>In both cases you are dealing with user input - and whether either is
>deterministic over time depends on whether the underlying data gets
>updated.

The first case was an example of a link *not* generated by a form, but
instead just a kludgy way of addressing a row in an RDB.

>The server does not know whether the user typed something to construct
>the URL, or whether the entire URL was embeedded in an HTML page; it
>only knows it has a request.

Right, and this is a problem. The server cannot tell the difference
between an address, a data submission, and a query.

>Saying that
>
>>    http://foo.bar.com/myrdb/1
>
>is deterministic is also not necessarily true. It depends, among other
>things on other headers supplied with the request and with imponderables
>on the server side regarding updates.

This is true, of course, but it doesn't negate the point I was making.

>> There are cases, obviously, where people might go off, execute a
>> search, and find something interesting to pass along to a friend. In
>> such a case, some people would argue that you should be able to write
>> down the URL *including* the query. I disagree, and think that there
>> are better ways of accomplishing the same thing. In a reasonable
>> hypermedia system, you should be able to create, and name, a query link
>> that people can link to.
>
>That is the crux of the problem - GET urls can be written down (they
>need not be short, but they can be written). What you get back is not
>necessarily what someone else got back, of course - regardless of the
>presence of a server-side specialiser character (ie ? )

Right. URL's as they stand today muddy the waters too much.