Question

Background
I am interfacing with a SOAP webservice, using C#. I am working in Visual Studio and have successfully set up a Service Reference and can use the web service in my code.

My questions are related to “how best” to design the client/wrapper to the API, considering the powerful features of C# as a language.

Central “Request” Class
I had the thought of creating an overall class to handle the requests to the service, and thus handle all of the various permutations of API specific errors (there are many), and degrade gracefully. This class could also perhaps be the “Controller” for the API client, which also provides the overall interface between internal calls and the outside world/code.

Then I noticed the sheer variety of data types that each API call requires and can return. Surely this means this “request” functionality cannot be handled generically (and must be implemented in each specific type of request – e.g. authentication, vehicle positions, jobs/orders)?

Or if it can, how can C# as a language, help me in working with types in an abstract manner?

As always, thank you for your time in reading and any advice you can spare.

Answer 1

The question is a little vague on details, but I’ll try and offer up some advice.

First I think you’re wise to create a wrapper over an external API. I’ll use the example of an external email provider to try and answer your question.

Imagine we have a third party email API and we want to make a wrapper around it.

I would start by making a wrapper that behaves the way I would expect an email API to work. There should be methods like:

public EmailResponse SendEmail(EmailRequest request) { }
public User GetUser(string email) { }
public void OptOut(string email) { }

I start by designing what I as a client think is both generic for the domain – and easy to use.

Then you make an implementation of the wrapper interface that maps directly to the third party API. In the example above, maybe it takes two external API calls to send an email, but the person using your wrapper won’t know that.

In my opinion wrappers are worthless if you bind them too closely with a specific implementation.

C# has tons of language features that make this kind of approach possible, but I think just using a simple Interface will fit your needs. No need to make it harder than it is.