3

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.

George
  • 901
  • 9
  • 23
  • Two votes to close? Seriously? Can someone provide some justification as to why this is not good enough for Stack Overflow? – George Feb 10 '13 at 12:34
  • You ask if your over complicate, well, the question is way over complicated. It's very hard find a clear answerable question. – Petter Nordlander Feb 10 '13 at 12:55
  • Hmm, just struggling to find a happy medium between not providing enough background information, and providing too much. The question is essentially - what is the best way to do the above, considering the language features of C#. – George Feb 10 '13 at 12:57
  • OK - question edited substantially. Hopefully this is better :) – George Feb 10 '13 at 13:07

1 Answers1

2

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.

ryan1234
  • 7,237
  • 6
  • 25
  • 36
  • Thanks for your reply and sorry for the late response. Actually this is ironic as I had to edit the question as it was too verbose! The main problem I am currently faced with is a problem of abstraction/design. I will need to check every request to the API to check for an existing auth session, for example. This means I will need a central "handler" method that everything else will derive from. Although I am unsure how this is doable in C#... – George Feb 12 '13 at 17:59
  • 1
    Check out AOP. It creates cross-cutting concerns. I've used AOP with WCF before. It's awesome for caching/logging/authentication, but it does introduce some overhead. http://stackoverflow.com/questions/1416880/aspect-oriented-programming-in-c-sharp – ryan1234 Feb 12 '13 at 19:18