On 28 July 2010 21:58, Alexander Johannesen <[email protected]>wrote:
> > > Hola, compadres! > > Sorry, I was meaning to reply to Steve earlier, but reality got in the > way. Anyway, I'll respond here, and I think this is the crux of what I > would have said is well covered so far and with this ; > > > mglendin <[email protected] <mikeg%40dulciana.com>> wrote: > > Although REST has gone nowhere for [more than] 5 years, > > that is simply because it hasn't needed to! The specification > > is just as valid today as it was back in 2000 or earlier. > > Exactly. I'm actually curious as to where Steve need it to go? What is > it that's missing? If this is going to be another SOAP vs. REST thing, > then again we need to point out that when people say "SOAP" they > really mean "WS-*", and voila! we're comparing apples and puckernuts. > SOAP isn't going anywhere either, to point out the obvious. > I'm talking about adoption. I'm suggesting that if REST really was a great technology approach that we'd have seen it adopted across the market in a broad way by now. SOAPs adoption is miles higher. Its not about comparing technology X v Y, its about comparing how people have adopted those technologies. > > The WS-* stack can always be improved upon, but what REST part can you > compare it to? The semantics apply to very different parts of each > solution, and some specifics of WS-* address stuff that is solved in > REST, some parts that are solved by HTTP (or some other protocol) > specifically, other parts that are solved by HTML or parts of it. > > I'm hearing Steve thinks REST stole the WS-* thunder to the point of > loss of innovation in that space? Hmm. I think people rather > discovered that WS-* was too an expensive platform to invest all > integration on, and that perhaps lots of what we do can be solved > cheaper and as well through simpler means. > My point is... no they haven't. The vast majority of people are still doing WS-* when they want to do system to system integration. > > > > Because of the scale of the deployed environment, evolving the > > technical infrastructure of the Web is now rather a difficult problem, > > as we have seen with the failure of HTTP-NG and the struggle of > > the "Web Standards" and now HTML5 movements to update and > > agree on even the basic technology standards on which the Web > > is based. I believe, however that the Web will evolve, and we will > > ultimately replace HTTP, but it will require a much stronger > > economic imperative than currently exists to do so. > > I feel you're being a bit too pessimistic about the history of all > this stuff. Better to be slow and awesome than fast and boring, I say. > The Web evolves, and at given times in specific ways. Some times it's > only a small part of it that moves, but as one part moves, some other > parts snap into place. The increase in bandwidth is pushing more and > more stuff onto the line, and our browsers needs to keep up with > demand, demand drives innovation, and lots of people try very hard to > innovate in order to a) stay alive, and / or b) get the upper hand. > IE5 introducing XMLHttpRequest flipped a large button. HTML5 will kill > Flash for sure. Google Chrome killed IE7 and whipped FF into shape. > Apple taking on WebKit with Safari changed everything. All of this > stuff happens around the user level of HTTP, extending and pushing > HTML boundaries. More and more apps are pushing their way into the > browser thin-client layer. And it's moving very fast, the distinction > between front-end and back-end is somewhat flattening out. Whole apps > can run in the browser with minimal AJAX to a DB (or some browsers > internal DB). Browsers are more and more becoming brokers of rules > between users. > For me the challenge isn't USERS its about System to System. > > In short; whole swarms of earlier REST / WS-* operations have shifted > into other layers. Things are messed up. And yet, HTTP still works > excellent. And the thing is that since the world revolves around this > HTTP concept you'll find cheaper ways to do WS-* stuff since the needs > will overlap. I don't think HTTP will be replaced, but perhaps > polished a bit. Is there a need to change it? Or is the idea to kill > it as other protocols are taking over? Ok. I'm fine with that, but I > doubt it will happen. > > ... > > > > More recently, we have moved on to arguing over the additional benefits > > of the various "envelopes" in which we can move information around, for > > example whether data is wrapped/contained within XML, SOAP, (X)HTML > > or ATOM. > > Don't forget JSON and the leveraging to browsers and JS engines. But > yes, not sure these conversations are too fruitful. You know what will > happen? Someone will pop http://nodejs.org/ running natively on their > browser, and AJAX event-driven notions will surge through all RIA's, > while the back-end also doing nodejs can synchronize and do the > back-end equivalent. It'll blow a *lot* of middleware out of the > water. (Many years ago I dabbled in JS programming on the backend, and > it was a refreshingly interesting experience) > > > > The more interesting and in my mind more useful debate is over > > the semantics of what happens to the information at the endpoints: that > > is, what real world effects can we achieve by exchanging this > information. > > Surely it is for these effects that we build systems in the first place > > and the reason we are paid to do our jobs as IT professionals? > > Ah, yes! My favorite! I've been pushing ontology-based business > applications for over a decade now, and it's starting to slip in here > and there. It will be the next thing, I'm pretty sure of it, but there > we're waiting for just the right set of tools and techniques to pull > together (although > http://ontopia.wordpress.com/2010/06/28/ontopia-5-1-0-released/ has > recently been open-sourced. A partial port to JS is in the wings, and > when TM or serious tuple-parsers enters the browser JS space, things > will happen, I'm fairly sure of it) as there's a growing awareness > that the many translations we do in our business applications are the > *main* reason integration and communication is so hard (and costly). > > > > As far as I can see, the current REST specifications and implementation > > frameworks being developed do not address these issues at all. In > > my opinion, the quicker we can get the industry onto debating these > > topics, the better! > > The advantage WS-* had here is of course that some big boys sit around > a camp-fire and make up what the different parts mean, and that's the > spec, use as described (with some expensive projects early on to > challenge those semantics). The REST / Web seems much less rigid than > that, arguably because they cater to a much, much larger user-base, > and the semantics are tested on a more continuous basis. > REST is not catering to a larger System to System user base than WS-*, its catering to the browser based piece (which is fine, but the argument was made that REST was good at System to System). > > RDFs will probably help a little here, and when business applications > can digest that, cTM, Turtle, CoiNs, MicroFormats (well, some of them) > and so on things will get smoother. The interesting part here is that > there are definitions that are coming out (ontologies) that have > serious backing, both in the normal and enterprise world, backed by > large organisations and corporations, and these will be used as a > first-generation set of languages. I suspect what we currently think > of as middle-ware will be replaced a new set of tools that are > semantically based (but that's a post for another day :). > I'll bet that they won't be. At least not in the TBL way of semantics. Semantics as a better XML description language I'll give you but the key point that all of these approaches miss, and why REST has failed to make decent headway in the market is that it solves a technical problem which isn't really a business problem. The problem in IT is how to help PEOPLE build systems more efficienctly. REST does not solve that problem and indeed is a step back from WS-* in making people efficient. Technologists continue to build better and better wheels, when what we need to really focus on is steering. Steve > > Regards, > > Alex > > -- > Project Wrangler, SOA, Information Alchemist, UX, RESTafarian, Topic Maps > --- http://shelter.nu/blog/ ---------------------------------------------- > ------------------ http://www.google.com/profiles/alexander.johannesen --- > > >
