--- Steve Jones <[EMAIL PROTECTED]> wrote: > > You need to do the same standardization effort for both styles and > I claim that defining a media type is a lot easier than defining an > API. > > But that isn't a claim backed up by experience of distributed systems > which has been successful via APIs but you are saying the new way > _could_ be easier but don't have the proof point. You might be right, > but I need data to back that opinion up.
I suppose it's "proof by inspection" but one could also count the number of internet nodes under different agency and observe how the netwrok is used. Specifically, I'd look at the properties of the popular application protocols that have a variety of implementations of both client & server. The fact is that when one introduces a new media type, it works with any of the Internet's Network-based APIs (i.e. transfer protocols). Examples include HTTP, NNTP, FTP, SMTP, IMAP, etc. The key isn't necessarily using "MIME" specifically, it's the importance of separating operation semantics from media type semantics. I'd also note that HTTP is increasingly taking over from SMTP,POP3, and IMAP as a way of sending & receiving email. There are many emergent factors to why this is happening, but the properties required to enable such emergence are arguably due to the architecture of HTTP. Approaches to Internet-scale computing with only custom operations & protocols have mostly been successful if a single entity controls both the implementation of both clients & servers (e.g. Napster, Blizzard's World of Warcraft), unless the protocol has relatively simple semantics to reverse engineer & cross-test (e.g. multi-network instant messaging clients like Trillian). > > Really, I am totally not getting your point. Can you explain? > > You talk of standardized MIME types, a theoretical thing, being the Seems to be working quite concretely for Newsgroups, Email, and Web pages today. > "solution", I doubt that we will get to a complete ontology of MIME > types that is standardised across the globe and therefore REST MIME types are just identifiers, not ontologies. To contrast, I don't think anyone's aiming to create a global ontology out of XML namespaces. They're both useful tools for disambiguation via registries. > WS-* is further along in the standardisation of industry verticals > and > this is liable to accelerate in the next 12 months. I'm just not > seeing the business case for them re-doing the effort for REST. One arguably can create RESTful stanards on top of WS-*, though it's unclear whether they'll flourish since they often lack cheap & robust enabling infrastructure to complement the specifications. OAGIS, for example, has done this very thing by separating nouns & verbs in its specifications. These specifications are on the right track to being RESTful, though they lack support of a standard set of processing infrastructure to provide working, freely available, code on how OAGIS proxies, gateways, etc. would work. HTTP & HTML had the benefit of a freely available Mosaic and Apache in its early days. I don't think the REST camp wants anyone to redo their industry vertical specs, as I don't think that's their area of interest. If industries are successful with such things, that's great. But, frankly, many believe (and I include businesspeople in this category) that such efforts are a waste of time, since they'll inevitably be subverted by competition. As an aside, if anything is true in this industry, there *always* is a rebuild & respec of the infrastructure every 10-15 years. The old stuff doesn't go away, but open source developers come up with new ideas, academics create new theories, and vendors keep needing to sell the next shiny thing. It will take a monumental change in the long term investment valuation of software and IT assets for this trend to change. One can hope.... Cheers Stu ____________________________________________________________________________________ Any questions? Get answers on any topic at www.Answers.yahoo.com. Try it now.
