Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Re: Why REST? (RE: WSIO- With Name)
 From: Paul Prescod [mailto:paul@p...] "Bullard, Claude L (Len)" wrote: >> >> Admittedly, I am using email very loosely here, a simplification >> to mean no state is guaranteed, only expected. For some reason, >> UDDI has methods that are very precise about expectations. I want >> to know why they prefer that over REST because even to me, URIs >> that identify known sources of typed information are easier. >Dunno. You should ask them. ;) You mean "They" aren't on XML-Dev? I thought everyone who was anyone on "The Web" was on XML-Dev. What a let down. This web services thing must not be very important if they don't even know about XML. (poke at MS commercial). >> It means that all I have to know to work from Google is www.google.com >> and a possible search term. >Right. Because web objects have an extremely simple interface in the OO >sense and they always support GET if they support anything. But also because that will always return a search page. The cognition for the transaction is the search term and subsequent terms I submit through that user interface. >> ... After that, it is discovery-based if I have >> the discipline to stay on track. However, unless I am very confident, >> I deal with a response of lots of sources through which I must browse >> to find the useful ones. >Okay...I'm losing the thread here.... Precision. Discovery. Google is only as good as I am able to cognitively recognize a precise term, a precise message to send which it will interpret as a request. Otherwise, I get a few to a few thousand candidates back. >> REST is. It doesn't send or expect state. It expects a representation. >The representation is, in general, the representation of some *state*. It's a document, packed in a URI or in the body, it's a document. I'm not so sure Fielding did much more than the genCode and GML guys did in recognizing that documents are how humans formally communicate instructions (ok, gestures, speech acts, etc. but these are bits on the wire with character encodings, so, docs). >> How is that different from packing an XML file in a POST? >There's nothing wrong with packing an XML file in a POST. XML is just a >syntax for a message with some semantics. It's a syntax until the right interpreter interprets it according to the local semantics. URIness is just address space. Until it is associated to a type (you like MIME), it is meaningless. >You go wrong when you start to >mismatch the semantics with the Web's natural data model, which is >resources, URIs and representations (i.e. REST). Ummmm... REST = Document. Otherwise we are just overloading function names. If we do that, why not just use functions (what UDDI does). >Putting the parameters in the URI makes the query >addressable. It means I write the query's name next to its address on the front of the envelope. >> But not FTP. FTP let's me get and set directories, change file names, delete files, >> and so on. >HTTP also. DELETE deletes files. GET and PUT renames them (though there >is an HTTP extension called MOVE which is an optimization). Getting and >setting directories are primarily a convenience for interactive use. Convenience may be at the heart of UDDI. Is there anything wrong with convenience? Seems to me we accepted a lot of retrograde tech to get the convenience of universal addressing. I don't particularly enjoy stateless programming. It's a pain in the neck and not very fast. ;-) >URIs are so much more flexible than the siloed naming schemes >available in those protocols. Flexible or just won based on a momentum that then hit a brick wall of economics. We don't want to throw the baby out with the bathwater, but saying "on The Web" sells exactly nothing these days. In fact, it raises suspicious eyebrows (which is why you are being put through this grilling). I agree that a universal address space has advantages, but really, that is DNS for this system. URIs are a way to put an application on the top of that based on naming conventions and letting HTTP be the proxy master. If MS had proposed that originally, most of you would still be using FTP and WAIS. <offtopic>The brilliance of MS was realizing their bad reputation was their strongest asset when it came to directing the evolution of "The Web".</offtopic> > ... In email, I send a request wrapped in > an envelope to an address I know a priori because based on description or > discovery, I have confidence the mail returned will contain a range of > messages I expect, or I have to discover that address. >Yes, but email is queued and thus almost never works at interactive >speeds. And email almost always involves several intermediaries which >[expletive deleted] away even more speed. And as discussed above email has no >"commands" (although SMTP *does* have commands). That is a literal email client. The point is the problem of the a priori agreements based on discovery. UDDI says that discovery should be quick and precise, dedicated not to generalized search, but to registries of business types with precise commands for drilling down to get the stuff you want when you want it. >> ... Google seems to me >> to be a very inefficient way to conduct a series of business transactions. >The search part of Google is not what REST cares about. Very true. Discovery is what UDDI cares about. It is what the user cares about. REST is another way to say, at this address (if you know this address) is a document that tells you the state of this resource at this time. UDDI is "in accordance with the conditions we have agreed upon to this time". I need to understand how all of the rest of that is done because an address is not enough. In most cases, a name is not enough. > Why do you think UDDI is designed the way it is presently as methods? >Objects on the brain. I dunno. Why do you think UDDI was hyped as >solving problems that only strong AI could solve? I missed that bit. Hype is what we do to get a crowd. After that, it is lecture or con. What I am slowly and belatedly learning is that success in business is a matter of wiring money to money. The rest is just negotiation. What I do know is that given the WSIO, powerful forces have decided to go forward without REST. Maybe without food too. I'd like to not see another dot. bomb because if these particular forces get it wrong, it will be more than a few hundred thousand misguided dot.commers on the street this time. To rephrase: even if it isn't RESTful, even if it isn't "The Web" as some polity defines that rather abstract incantation, will UDDI work 'well-enough', because if it does, then the usual rubric of "running code and rough consensus' is met. On with the wiring. len 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
