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]> 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. 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. > 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. 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. 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 :). Regards, Alex -- Project Wrangler, SOA, Information Alchemist, UX, RESTafarian, Topic Maps --- http://shelter.nu/blog/ ---------------------------------------------- ------------------ http://www.google.com/profiles/alexander.johannesen ---
