Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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:
/project1/search/getstuff?etc...
/project1/analysis/getstuff?etc...
/project1/cluster/getstuff?etc...

/project2/search/getstuff?etc...
/project2/analysis/getstuff?etc...
/project2/cluster/getstuff?etc...

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()
{
  _searchclient.getStuff();
}

Any suggestions how I can architect this better?

share|improve this question
    
Why do you believe that the public methods are a problem? –  Robert Harvey Feb 2 '11 at 17:17
    
off topic, but looks like those services are the very antithesis of REST. –  qes Feb 2 '11 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 Feb 3 '11 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.

share|improve this answer
    
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 Feb 3 '11 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. –  qes Feb 3 '11 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) { ... }
}
share|improve this answer
    
Isn't that just pushing the complexity somewhere else, "kicking the can down the road," so to speak? –  Robert Harvey Feb 2 '11 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? –  Steven A. Lowe Feb 2 '11 at 20:17

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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