Wrapping REST based Web Service

Question

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!

Answer 1

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.

Answer 2

I've built a rest service wrapper or two.

You shouldn't really have to worry about the partner adding fields -- the serialization will move past that with ease in most cases. Well, unless you shoot yourself in the foot and start using schema validation on the returns from your partner. Removing fields won't cause a crash at the point of import in most cases but it can cause some interesting effects down the line. The only crash issue is if your partner starts changing types on you -- such as deciding an identifier is really a string not an integer. That said, it is pretty well understood how to version APIs in 2012. Unless you are facebook, you don't randomly change things on your partner. If the blob storage is one of the 3 likely candidates then I'd expect the API to be nearly set in stone -- there are enough clients out in the wild for those that they could not change without ruining a few million hipsters days.

That said, how I would build an early warning system for this sort of scenarios would be to write my wrapper library in a test-driven way, making sure to cover the deserialization parts really well and with fine-grained detail. Then use a CI server to automatically run the service tests on said library every other hour or so. If the tests are good, you will have a very good idea what changed, when and how it hurts and perhaps how to fix.

But I really wouldn't worry about this too much given decent instrumentation and error handling in your product.