Web Services – Do WSDL-Based Services Require SOAP?

If you are doing an AJAX heavy application then one pro about REST is you have the option of using JSON as your data-interchange format instead of XML. JSON requires less markup than XML so that would speed up your application since you would be sending less data over the wire.

It also seems that REST is over taking SOAP with web services, and its always a good thing to use a technology that is more widespread when you bring on new developers or if you want other developers to consume your data.

The pro for SOAP is that it already has structure built into it, but I don't see why you can't build your own structure into your REST solution.

EDIT: When I did telecom programming our phone switch only supported SOAP and not REST. I found that SOAP required a bunch of boilerplate stuff that just got in my way when I didn't need it.

Although you say it's not what you need. Your question DOES suggest not creating a web service at all but to use a reverse proxy on their webservice. Any access will go through your reverse proxy which you could redirect at will.

Alternatively you could do some basic enveloping of their responses, wrap their XML or JSON in your own. You would not need to look at the XML or JSON at all or be effected by changes in it's schema.

On the other hand, if you were to switch to a different partner service. Do you think their data will look exactly the same? Would your clients be able to work with it without modification?

You could use your 'wrapper' service as a facade to make sure the data provided complies to your defined structure. In such a setup you would not automatically let through whatever field a partner may add. Your webservice would make a partners webservice comply to a certain contract. Basically protecting the client programs from unexpected changes.

Of course you could add a little pockets of key-value pairs here and there if it makes sense (the data being dynamic). Don't need a dynamic programming language for that.