Geek Answers Handbook

Three similar APIs - best design?

I'm looking for some thoughts on which design patterns to use for my problem, regardless of language.

I have access to three APIs that have different interfaces and functionality, but all of them for the same purpose return information to me in the same way, about the same type of content - the authors of the blog.

Some APIs do exactly what I want, some require API + Screen Scraping, etc.

The obvious choice seems to be the adapter template, but I want to really understand the design of this thing, and so your thoughts will be very grateful!

To be absolutely clear, right now I am introducing one class for each web service that does the core API stuff, as well as less elegant things. I assume that it returns uniform results in its adapter. I assume that the adapter uses a method such as Search, and then redirects it to the appropriate method in the API and returns results that will look the same no matter which service was called.

If this sounds like homework, it is - but I assigned it to myself to learn some cool sample template. Is the adapter correct? Any other good options?

Thanks in advance!

UPDATE: Although the models of adapters and facades seem a lot to me, Paweł Dyda points out below that what I am describing is really a Facade, not an Adapter. I agree. Does anyone think that there is a better option than the Façade, assuming that the number of APIs is growing over time?

Thanks again.

+4
source share
4 answers

An adapter is a design pattern that adapts an existing API to another existing API. What you are talking about is actually a façade and yes, it seems like a good way.

+3
source

I don’t think you need a facade or adapters. It seems to me that this is a simple case of having interfaces with several specific implementations. For instance:

interface IBlogApi { IBlog GetBlog(string url); } interface IBlog { AuthorInfo GetAuthorInfo(); } class BloggerBlog : IBlog { public BloggerBlog(string url) { // ... } public AuthorInfo GetAuthorInfo() { // ... } } class BloggerApi : IBlogApi { public IBlog GetBlog(string url) { return new BloggerBlog(url); } }

With this type of customization, one design pattern that you can use is the Factory pattern. For instance:

 public class BlogFactory { public IBlogApi GetApiForUrl(string url) { // Dumb example... if (url.Contains(".blogger.com")) { return new BloggerApi(); } // ... } }
+2
source

Duck type, add the getAuthorInfo () method for each class, it may add an interface, but it probably isn’t even necessary.

Premature abstraction is the root of all evil.

0
source

Sounds like a facade pattern. It is always recommended to encapsulate third-party api interfaces from the rest of your code. In the next step, read at least the GoF template book. He describes most of the patterns in clear software.

0
source

More articles:


All Articles