I am integrating with a set of REST services exposed by our partner. The unit of integration is at the project level meaning that for each project created on our partners side of the fence they will expose a unique set of REST services.

To be more clear, assume there are two projects - project1 and project2. The REST services available to access the project data would then be:


My task is to wrap these services in a C# class to be used by our app developer.

I want to make it simple for the app developer and am thinking of providing something like the following class.

class ProjectClient  
  SearchClient _searchclient;  
  AnalysisClient _analysisclient;  
  ClusterClient _clusterclient;  

  string Project {get; set;}  
  ProjectClient(string _project)  
    Project = _project;  

SearchClient, AnalysisClient and ClusterClient are my classes to support the respective services shown above.

The problem with this approach is that ProjectClient will need to provide public methods for each of the API's exposed by SearchClient, etc...

public void SearchGetStuff()

Any suggestions how I can architect this better?

  • Why do you believe that the public methods are a problem? Commented Feb 2, 2011 at 17:17
  • off topic, but looks like those services are the very antithesis of REST. Commented Feb 2, 2011 at 20:10
  • Robert Harvey - Wouldn't I need to provide a wrapper for each of the APIs exposed by SearchClient, AnalysisClient, etc...? It just feels wrong.
    – user15370
    Commented Feb 3, 2011 at 14:35

2 Answers 2


Why not make it easy on your self - both decision-wise and implementation-wise - and just use one of the many frameworks that already exist to consume Web API's, like RestSharp or Hammock.

  • Thanks for the suggestion. But I don't see how using RestSharp is a solution. I already have a REST interface built that my SearchClient, AnalysisClient, etc... subclasses. I want the app developer to only instantiate an object that maps to the set of REST services exposed by a particular project. Perhaps ProjectClient should subclass the REST interface.
    – user15370
    Commented Feb 3, 2011 at 14:51
  • Perhaps I misunderstood your question. I thought you were looking for how to design classes that consumed a web api. With that assumption, what I was meaning was to use a library, which will drive the design of the classes. For instance, RestSharp would generate them with T4 templates. But it seems like I maybe missed what you were really asking. Commented Feb 3, 2011 at 15:58

an interface for each REST project, one class per interface, with a static factory

in other words, the ProjectClient class as presented violates the single-responsibility principle (and verges on being a 'god' class). I suggest:

public static class ProjectClientFactory
    public static ISearchClient MakeSearchClient(string projectUrl) { ... }
    public static IAnalysisClient MakeAnalysisClient(string projectUrl) { ... }
    public static IClusterClient MakeClusterClient(string projectUrl) { ... }
  • Isn't that just pushing the complexity somewhere else, "kicking the can down the road," so to speak? Commented Feb 2, 2011 at 19:41
  • @Robert: i see no complexity in this - one project, one interface, one class; the factory hides the concrete classes and the interface hides the implementation. What do you suggest? Commented Feb 2, 2011 at 20:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.