creating API using adapter pattern

I am working on an API for several web services, which all return a list of products. However, the objects returned are quite different. They have some overlap in member variables and methods, but also a number that are either conceptually different or slightly different. What would be the best way to structure the API? I think this is the adapter pattern, but I am not sure.

So e.g. my class has (pseudocode, not a real language)

member: webservice (type:object, can be a numbe开发者_JS百科r of types, all adhering to the same interface)

method: setCurrentWebservice(service) {self.webservice=service}

method: getProducts() { return self.webservice.getProducts();}

Also some methods are supported in one webservice, but not in the other. Should I make 'method-not-supported' methods? What should those return?

From what you describe, then use what you will need to write is some form of adapter to unify underlying implementations.

If the aim is to provide a uniform interface over the two service API's and to hide the fact that there are indeed two different implementations, then you will need to aim to hide all the differences between the two services from the user of your final facade. This will take some work because, as you point out, one service might support one method but not another.

If the aim however is just to provide the same interface only to make it easy for the user to switch between the underlying implementation they wish to use, then this may be less important. You can probably just document that implementation x does not support method y.

There are no hard-and-fast answers here: in the first case you need to be clear on the motivation because I believe as I have said that there are at least two possibilities and each one probably requires a slightly different approach. But to answer your question, yes, you need an adaptor, but quite how you want the adapter to behave that is only definable if you state the reason for providing this API in the first place.