Re: Content Sniffing impact on HTTPbis - #155

Thank you all for this discussion.  It appears that the path of least
resistance is for me to change the terminology in the next draft,
which I will do.

Adam


On Tue, Jun 16, 2009 at 9:47 AM, Roy T. Fielding<fielding@gbiv.com> wrote:
> 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
>
>
>