Re: Content Sniffing impact on HTTPbis - #155

On Jun 16, 2009, at 7:45 AM, Jamie Lokier wrote:
> Ok, but what about a resource that accepts POSTed information _and_
> information in the URL?  For example a hypothetical POSTable
> http://example.com/post-news/author-is/Jamie/subject-is/Good%20morning
>
> Then the URL doesn't point to the conceptual resource any more.  Part
> of the URL does (http://example.com/post-news/); the rest of the URL
> does not identify a resource, but is input to it.

No, (http://example.com/post-news/) is not *the* resource.
It may be a resource, but it is not the resource to which
the URI above identifies, and therefore your assumption about
the meaning of "resource" in Web architecture is wrong.

> Conceptually it's a mistake to equate "the thing that a specific URL
> refers to" with the useful concept of a "resource that we may interact
> with", because the most useful mapping often doesn't work that way.
>
> You can say that the thing identified by the above long URL is a
> resource, but it's a bit of a stretch and doesn't fit what it  
> really does.
>
> So if it's a conceptual mistake, why is it useful in specifications?

Because it isn't a conceptual mistake.  Your mistake is assuming
that "resource" has something to do with the implementation behind
the server interface.  Ian's mistake is assuming that what people
refer to is the bag of bits they get back, as opposed to the function
being exploited by the request method on the server-provided resource
at the time of the request (e.g., if the link is to today's weather
report then the resource is today's weather report, not some former
weather report's bag of bits).

In any case, the word "resource" is far more commonly used the way
I use it than the way that Ian described.  As indicated, it comes
direct from the English language.  Ian's opinion is simply wrong
and you can't "simplify" a specification by defining the basic
architectural elements incorrectly.

....Roy

Received on Tuesday, 16 June 2009 16:48:32 UTC