Re: section 1, intro, for review

noah_mendelsohn@us.ibm.com wrote:
> 
>...
> 
> This is where we part company.   If what you're addressing is like a
> computer memory, then having an address space implies "GET" and "PUT".  If
> what you're addressing are email users, then I suggest there's at least an
> implication that what follows is not GET, but "Send Mail". 

Send mail is classic POST. For instance see NNTP's POST method.

> ...  Yes, it's
> handy if a "Get" from an Email address gives you something back, but I
> don't think that's the essence of being able to state my email address as
> a MAILTO: URI.

It's interesting you say that. Just ten minutes ago I was bemoaning the
fact that there is no way for me to state that my two email addresses
are equivalent in a universally accessible way. If only there was a way
I could convince the different applications that use my email address as
my identity to do a "GET" against an XML resource that would point them
to my other equivalent email addresses...

Wouldn't it be great if, instead of putting profile information in an
attachment or signature, it could be GOT (and cached).

> I am not, not, not, arguing for object oriented APIs as a foundation for
> the web, or even necessarily as good practice for many applications.   I'm
> just suggesting that anything you do that limits or unduly prejudices the
> "operations" you might want to do on on a resource is somewhat at odds
> with the universality of the web.

It's okay to suggest it but I would be more persuaded by examples.
Architects don't build buildings by saying: "let's leave all the walls
out in case someone wants to do something we didn't anticipate." Rather
they try understand what people need from their apartments and offices
and choose the right level of specificity or generality based on their
observations. In this case the walls exist, nobody has yet demonstrated
that they get in the way and I see no virtue in knocking them down.

Resources that support GET are, in general, vastly superior to those
that do not. And if you leave in GET as an option (even if it returns
404 today) then you may find a day or week from now that it becomes
really useful. For instance this is what people are trying to do with
XML namespaces. On that basis I would say that a web architectural
principle is that new resources SHOULD support GET, if even just to
return 404. And the Web should strongly prefer protocols that support
(at least) GET.

 Paul Prescod

Received on Tuesday, 19 March 2002 15:36:23 UTC