Every once in a while, something happens that makes me completely reassess my take on "what's next" in the technology sector. The original Macintosh was one such epiphany, Apple's Hypercard was another (Hypercard is a much-unappreciated program - had Apple added network links to it we'd have had a writeable, scriptable WWW in 1989). Netscape's first browser was a third. On Thursday, the release of Yahoo! Pipes shook my world.

The Pipes slogan is "Rewire the web", and that's what it purports to do - as a visual editor for RSS feeds that dramatically lowers the time and expertise needed to create a "mashup". Pipes lets you create your own personal web channels, and Gina Trapani at Lifehacker has a great example of how to do this.

And so, if your interest is, say, the NFL draft, it's pretty easy to wire up all the draft-tracking sites so that if a potential 7th round pick out in East Treestump gets a hangnail, you'll know about it. But the implications go so much further...

In a REST-ian world, it's pretty easy, once you've modeled your world as a set of resources, to create RSS feeds that track the changes in those resources. With an application like Pipes, it's really easy to tie those feeds together into new applications. This is the future of "SOA" and "Web Services."

Forget SOAP, and the growing pile of WS-* standards as a means of wiring up disparate applications. REST-ify the applications, use RSS to publish the changes, and a tool like Pipes (or one of the imitators that should be quick to follow) to wire the whole thing up. SOAPians - put that in your pipe and smoke it!

Seriously, though, while the Pipes idea is great, there are still some issues to work through. The intuitive purity of the Pipes concept was proven when everyone from the merest script-kiddy to the deepest hacker jumped on Yahoo! and bought the Pipes site Down! all day on launch day. Yahoo! knows a bit about keeping large sites up under volume, so we are surely talking about a big human wave here.

But that's not all, either. XML is wordy, and XML transformation is slow and computationally intensive. I'm curious to see if the sheer processing load leads to more restricted (e.g. JSON) or more efficient/binary formats as a wire protocol for Pipe-y services.

I'm convinced these things will be worked out, and Tim O'Reilly's comments about Pipes as a "milestone in the history of the internet" will prove to be true.

As such, let this be my 14th prediction for 2007: February 7, the Pipes release date, will be looked back on as the day SOAP died. Not that it's bad, but the future has been shown to lie elsewhere.

Prediction: APIs rule, and REST will come to rule APIs in 2007.

Google rules the Web 2.0 world. They are the alpha and the omega, from Google Maps (which popularized Ajax and got the whole thing started back in 2005) to being the primary acquirer and exit strategy for many Web 2.0 companies. Google is also the whole alphabet in between, and their publishing of APIs for their applications re-ignited the "mash-up" concept from Web 1.0, and changed the face of web apps we see today.

Google is wise and omnipresent, but they aren't omniscient. Back in 2002, when the current round of API design decisions were made, Google had the choice of creating an API in well-known media-darling SOAP, or the little known academic paper-protocol REST. They chose SOAP. Not that SOAP was such a bad choice, but with the benefit of hindsight Google is now heading in another direction, and Yahoo has already reached the promised land.

SOAP (originally Simple Object Access Protocol) was a neat idea—to replace the bulk and complexity of integration schemes such as CORBA with a simple combination of XML and HTTP. Great idea, but to provide fully-functional enterprise integration SOAP had to expand, eventually absorbing much of the complexity of the protocols it meant to replace.

Enter REST. Representational State Transfer is the brainchild and 2000 PhD dissertation of Roy Fielding. Fielding observed that one of the great advantages of the HTTP specification (of which he was also a contributor) was that the client-server, stateless, cacheable, and layered design made access and architecture for the specification straightforward. REST extends these concepts to application-application communication. Very broadly, REST maps the basic CRUD operations (create, retrieve, update and delete) to familiar HTTP operations (POST, GET, PUT, and DELETE). As an additional conceptual benefit, these operations also map analogously to the database operations INSERT, SELECT, UPDATE, and DELETE.

Boiled down, the idea is to have applications interact through conceptually simple HTTP access for exchange of resources—remote resources, as opposed to remote procedure calls. API creation is then a breeze, because the access methods are already broadly familiar, and the receiving applications need only be ready to respond to requests based on the request information in the HTTP header - say for HTML (web pages), JavaScript (Ajax requests) or XML (application requests). Ruby on Rails has good REST support now (through the SimplyRestful plugin) and will have REST as a part of the core going forward.

In the Ruby/Rails world, URL's are beautiful and informational, and one of the downsides of REST are URLs that are more machine- than human-readable. Still, as applications are increasingly designed with integration and mashup in mind, you can expect REST to rise in prominence in 2007.