What makes me quite annoyed is grand statements such as the title to this post.
It is true that REST is getting more exposure these days and it being primarily a connectivity technology i.e. a web service it's not unlikely that SOA and REST will inevitable get linked together.
The Burton group has stuck it's neck out and said that yes REST is the future of SOA. Funnily enough today at work I was talking with some colleagues about REST and one raised a good point, where are the working examples? So lets not start betting the farm on something that hasn't been proved yet!
REST has more than afew hurdles to get over before it reaches the mainstream adoption that WS-I web services currently enjoys and they are.
1) A concrete definition of a RESTful web services, there seems to be quiet a lot of confusing on what exactly does this mean. Something like the four tenets which Don Box wrote about was indeed very helpful in clarifying the advantage of web services. Yes there are good definitions already but they are to abstract and the meaning is lost with interpretation.
2) REST is simple but the consequences of it's adoption are like opening a can of worms, they are far reaching which developers will have to think and design systems in a much different way than they do currently.
3) REST isn't something today that's integrated into development tools such as Visual Studio. Some would argue that simple HTTP gets and puts are simple to code anyway, I would argue that this to low level from many mainstream developers, the tools that they will use will need to be comparable at least to what they currently enjoy this is why I find the Burtons group statement even more baffling, or perhaps they know something I don't as many development tool creators haven't put REST creation and integration high on the priority list.
4) REST will only succeed if parties that are involved in the WS-I can also agree on the implementation of REST, yes we are back to the definitive definition again.
To my mind that the success of a SOA isn't on the choice of a definitive service protocol that all technologies can use. The simple fact is that a successful SOA will for the time being have different service types for reasons of practicality.
For example entity service need to perform so there is no reason why they can't enjoy more than one interface, one being the generic web service but another being a .Net assembly that can plug straight in. Ok so this example doesn't protect against application specifics and comes with all sorts of baggage but having a hi/lo grade service isn't such a bad thing when we are trying to beat the laws of physics! The service boundary is still abstract and the purest's can call it an application implementation.
Anyway, I will keep an eye on the goings on in the SOA world. What I can say is that REST isn't just another fad but it's success will come from real world implementations solving real world problems so for now I will not throw my weight behind REST and will stay a curious observer.