I'm sorry, I agree with the XML/SOAP point but I think the rest is terrible advice. Doing webservices in a private idiom for each project is the opposite of consistency. REST only ends up inconsistent if it's abused/ignored. Using POST for every call is a kind of cognitive dissonance in design; why not just start over with POE or whatever and get away from HTTP completely. And Storable won't always even work between two different versions of Perl (even with nstore) let alone with anything else at all.
I wrote a fairly half-baked REST service (some is not particularly RESTy and I regret and hope to phase out those misteps) for our main application at work about a year ago. Someone in another group picked it up and prototyped an integration with their application in a couple of weeks. Other teams had been working (well mostly arguing about how hard it would be and how to design it) to achieve this for two years. We were fairly astonished at how well it works. The dev said it was easy because the webservice was so simple/clear/atomic; "brilliant" was the word used. I brought nothing to that particular party except attempting to follow REST principles. It was the most gratifying thing that's happened to me in this particular job in a looooooooong time.