Hmm, so the 303 status pattern is an _alternative_ to the hash fragment
pattern, yeah? After all, we just established that a server can't
decide on a status to return based on the presence or content of a hash
fragment, since the server doesn't get the hash fragment.
So I guess I come down firmly in the camp of preferring the 303 status
pattern to the hash fragment pattern.
I wrote a bit more about my skepticism of needing a special technique to
differentiate a URI for a "real world object" from a URI for a "web
document" -- to me this seems just like one example of a general case of
making sure you know what a URI represents and are not confused about it
representing something different than you think; "real world object"
confusion doesn't seem special to me here, and in fact it's kind of
confusing deciding whether certain things ARE "real world objects" or
"web documents"--certain things that may be "edge cases" for the web as
a whole, but are often central cases in the library domain (like a
scholarly journal; is that a real world object, or a web document?).
Anyway, I wrote some more about it in comments on a post by Pete
Johnston here:
http://efoundations.typepad.com/efoundations/2009/07/restful-design-patterns-httprange14.html
Ed Summers wrote:
> On Thu, Nov 12, 2009 at 5:47 PM, Jonathan Rochkind <rochkind_at_jhu.edu> wrote:
>
>> Personally, I've never linked the "httpRange-14" solution of doing fancy
>> stuff with fragment identifiers. It only leads to confusion in my mind. But
>> I'm kind of a heretic when it comes to this stuff.
>>
>
> Actually it's not that heretical of a perspective. Much of the
> httpRange-14 hubbub seemed to derive from people reacting to timbl's
> proposal to use hash fragments to aid in identifying *things*. Which
> is how the 303 status code pattern came about.
>
> I think the use of fragments in URIs for things is a great hack
> myself. But like many great hacks, it's a bit hard to explain. I
> always kind of hoped it was an implementation detail that most people
> wouldn't have to care about: like pointer arithmetic, utf-8, etc. The
> nice thing is that there are tools like Vapour that reduce the
> guesswork necessary.
>
> If you haven't run across it before Cool URIs for the Semantic Web [2]
> is really quite helpful in understanding the httpRange-14 issue, and
> how it plays out practically in web applications.
>
> //Ed
>
> [1] http://validator.linkeddata.org/vapour
> [2] http://www.w3.org/TR/cooluris/
>
>
Received on Mon Nov 16 2009 - 10:42:55 EST