- From: <noah_mendelsohn@us.ibm.com>
- Date: Tue, 19 Mar 2002 14:53:14 -0500
- To: Paul Prescod <paul@prescod.net>
- Cc: www-tag@w3.org
Paul Prescod writes: >> There is a standard for addressing things, the >> URI. It works brilliantly. It is the basis >> for the most diverse information system in >> history. It seems odd to me that I now have >> to prove that we should continue to promote >> its use. You don't. We're in complete agreement on URIs. >> But I don't see a way to implement the common >> address space without GET, and GET leads >> naturally to PUT and PUT leads naturally to >> DELETE and then you need a way to create new >> addresses and POST can do that. So HTTP >> "falls out" of addressing in my mind. 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". 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. 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. In any case, we have absolutely no disagreement on the signifiance and importance of URIs. Thanks! (So many people have responded to my notes, that in an effort to respond, I feel I'm taking too much of the list's attention. I hope other correspondents will take no offense if I don't send further individual responses. I think I've made my points, and I'd rather not contribute to an email deluge on this topic. Many thanks to all who have taken an interest, pro or con, in the points that I raised last night.) ------------------------------------------------------------------ Noah Mendelsohn Voice: 1-617-693-4036 IBM Corporation Fax: 1-617-693-8676 One Rogers Street Cambridge, MA 02142 ------------------------------------------------------------------ Paul Prescod <paul@prescod.net> 03/18/2002 08:53 PM To: noah_mendelsohn@us.ibm.com, www-tag@w3.org cc: Subject: Re: section 1, intro, for review noah_mendelsohn@us.ibm.com wrote: > > Paul: > > With respect, I think you're reasoning from the converse. I hear you to > say: > > * many, many things are well modeled by REST (true) > * perhaps the very counter-example David gave is a bad one > and could be handled by REST (possibly true) > * lots of folks are out there doing ugly things they shouldn't, > including failing to use URI's for addressing, and probably > failing to apply REST where it might have advantages > (true) Those are all accurate representations of my position. I am much more interested in the common address space than in GET/PUT/POST/DELETE semantics. But I don't see a way to implement the common address space without GET, and GET leads naturally to PUT and PUT leads naturally to DELETE and then you need a way to create new addresses and POST can do that. So HTTP "falls out" of addressing in my mind. But it falls out as a starting place. I would be happy to see something go beyond HTTP as long as it doesn't break addressing. > I don't think that proves that a shared memory (REST) is the right model > for all the resources we may reasonable want to integrate into the web. At > best it leaves the question open. There is a standard for addressing things, the URI. It works brilliantly. It is the basis for the most diverse information system in history. It seems odd to me that I now have to prove that we should continue to promote its use. I can't prove that it is sufficient to address the thought waves of ninja Andromedan space warriors. But it kind of stands to reason that if nobody has yet run into any limitations in using URIs to address anything that probably nobody will. I would like to be able to do a mathematical proof that all of these alternate address schemes can be implemented in terms of URIs but the problem is that insofar as their address schemes have no standard there is nothing for me to do a mapping FROM. All I can say is that I've never heard about someone who tried it and failed. Billion dollar businesses are built on URI-addressable information, in every industry. > ... BUT: in > another sense, there's something very different going on with the CDROM. > The semantically interesting specification for the spinning disk is not > "load/store", it's "Set speed", "Seek", "Eject", or whatever. Behavior is > encoded in the addresses. This is very, very different from a world of > shared memories or web documents. > > I think this teaches us that when REST is used to manage memory-like > resources on the web, we can get by with that one level of description. > When REST is used for other resources, the higher level semantics are at > best tunneled through a Load/Store abstraction. Sometimes that tunneling > is worth doing, sometimes it's better to admit that the resource is not > memory-like, and use a protocol more directly appropriate to the resource. That's an assertion that I would need to see backed up by evidence. As you point out, the CDROM works okay when you address it through the common interface. When does it become appropriate to invent a special bus just for the CDROM rather than building on the memory load/store model? Let's not get too bogged down in the analogy: any abstraction can get in the way when performance is a central goal. But if it is not, what's an example of a web service that is not sufficiently "memory-like" to be amenable to REST. And to get to the issue I am most interested in, what information exists that should not be addressable by URI? > I think we should at least leave that option open in the web > architecture. All I care about is that our "fix" to the web architecture not break the thing that makes it most powerful, the universal addressability of information. I'd also like to bring out a point: > > > * lots of folks are out there doing ugly things they shouldn't, > > including failing to use URI's for addressing, and probably > > failing to apply REST where it might have advantages > > (true) If a technology is uniformly misused, at what point do we start to blame the technology rather than the technologists? I don't see the experts using the current raft of web services technologies in a more sophisticated manner than the denizens of XMethods. I've documented the problems with the UDDI API. It was probably the first consortium-described web services API. Can you point me to a few well-defined, public SOAP/WSDL interfaces that you would claim would not be amenable to a URI-centric model? Paul Prescod
Received on Tuesday, 19 March 2002 15:08:56 UTC