[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: REST has too many verbs
On Mon, 2002-02-11 at 12:40, Paul Prescod wrote: > REST doesn't adore HTTP. It's the other way around. HTTP 1.1 was > designed as a protocol for REST. ;) HTTP 1.1 was built as a protocol for HyperText Transfer, to the best of my recollection. It's hardly a monument to architectural simplicity, though it does an excellent job of transferring and storing information built around the notions in HTML. > If you do that, you make it extremely difficult to build intermediaries > like: > > * store-and-forward services > * caches > * firewalls > * proxies > * message routers > * privacy managing intermediaries I don't believe that to be a true statement. You can't simply reuse (or, as some have noted, abuse) existing implementations of those systems, but it hardly rules them out. It does mean a shift from working with metadata to working with data, which may be substantial, but it's hardly the end of networking as we know it. > > Either approach makes it possible to, for example, recreate a given > > state by feeding in the data that led to that state, without having to > > retain additional metadata about what the headers were, what the > > response looked like, etc. > > That's the point of REST. You shouldn't have to re-create states. States > should have URIs. You should just point to the URI of the state. And if that state represents the results of a few thousand individual messages, how exactly do I recreate it in the event of a failure? URIs make nice destinations. That's about as much as they're good for without metaphysical metadata hocus-pocus. States are things as they are, not things as they are labeled. > > ... Archiving a set of transactions seems a lot > > easier in this case, and I suspect the processing is actually less > > complex. > > Don't know what you mean by that. It means that the messages are all you need to keep should you need an archive for backup or regulatory purposes. From a legal standpoint, it's nice to know how the contents of your data store came to be, not just how they are today. > XML is just a syntax. Surely the interesting part is in what problem you > are trying to solve and the data model you build up around that problem. > Then it becomes useful to ask which parts should go in the XML and which > in MIME. Sure, XML is just a syntax. That's what makes it so flexibly usable for this kind of application. I'm perfectly happy to work with MIME-based systems because they're what we have right now. I'm not willing to concede that MIME approaches are a good idea to continue supporting moving forward, however. > > I'd love to see an "XMLchucker" protocol that just opens a port, sends > > the info, and maybe replies with a checksum or an error. No more. > > It'll take about ten minutes to write the RFC for that. But your > intermediaries will have no idea what is going on and won't be able to > help you. They won't today, but they may someday. I don't believe this idea is inherently any worse than that of reusing HTTP in these contexts. -- Simon St.Laurent Ring around the content, a pocket full of brackets Errors, errors, all fall down! http://simonstl.com
|
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
|