0

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?

Improve this question
3
  • Why do you believe that the public methods are a problem?
    – Robert Harvey
    Feb 2, 2011 at 17:17
  • off topic, but looks like those services are the very antithesis of REST.
    – quentin-starin
    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
    Feb 3, 2011 at 14:35

2 Answers 2

Reset to default
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.

Improve this answer
2
  • 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, 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.
    – quentin-starin
    Feb 3, 2011 at 15:58
0

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

Your Answer

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

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