We have a number of existing asmx web services that are used by many, if not all of our clients. These are not going to be re-written en-masse any time soon.
My simple question is therefore whether it makes sense to create a new web.api layer that underneath call the existing web services where required (until they are rewritten) and new methods could do without the "legacy" soap services. What this would ultimately mean is that until the time the existing web services are re-written / ported to web.api then we'll effectively have two interfaces.
I know that things are generally heading in the REST direction, and so for future projects, interacting with web.api nay be a good way to go. Scott Hanselman has previously said that "if In doubt add another layer of abstraction", but I'm not convinced he was serious :)
The problem here is that the methods of your SOAP-based API are unlikely to map onto the more resource-orienmtated design of a REST API.
Also, from a performance point of view you'll wind up with something pretty clunky if you place a web service facade over a web service.
REST is increasingly popular, but it's not true to suppose that everything is moving in that direction. IMHO there are times when the structured exchange defined by a SOAP contract can make for a very useful API.
I certainly wouldn't bother wrapping an existing SOAP interface to create faux REST.