I am designing a system that will be running online under Microsoft Windows Azure. One component is a REST based web service which will really be a wrapper (using proxy pattern) which calls the REST web services of a business partner, which has to do with BLOB storage (note: we are not using azure storage). The majority of the functionality will be taking a request, calling our partner web service, receiving the request and then passing that back to the client.
There are a number of reasons for doing this, but one of the big ones is that we are going to support three clients: our desktop application (win and mac), mobile apps (iOS), and a web front end. Having a single API which we then send to our partner protects us if that partner ever changes.
I want our service to support both JSON and XML for the data transfer format, JSON for web and probably XML for the desktop and mobile (we already have an XML parser in those products). Our partner also supports both of these formats.
I was planning on using ASP.NET MVC 4 with the Web API. As I design this, the thing that concerns me is the static type checking of C#. What if the partner adds or removes elements from the data? We can probably defensively code for that, but I still feel some concern. Also, we have to do a fair amount of tedious coding, to setup our API and then to turn around and call our partner’s API. There probably is not much choice on it though. But, in the back of my mind I wonder if maybe a more dynamic language would be a better choice.
I want to reach out and see if anybody has had to do this before, what technology solutions they have used to (I am not attached to this one, these days Azure can host other technologies), and if anybody who has done something like this can point out any issues that came up. Thanks!
Researching the issue seems to only find solutions which focus on connecting a SOAP web service over a proxy server, and not what I am referring to here.
Note: Cross posted (by suggestion) from https://stackoverflow.com/questions/11906802/wrapping-rest-based-web-service
Thank you!
Best Answer
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.