The reason for doing it is to solve the case when a newer API is no longer backwards compatible with an older API.

To explain, just say that there is an old API v1.0. The maker of this API decides it is broken and works on a new API v1.1 that intentionally breaks compatibility with the old API v1.0. Now, any programs written against the old API cannot be recompiled as-is with the new API.

Then lets say there is a large app written against the old API and the developer doesn't have access to the source code. A solution would be to re-implement a "custom" old API v1.0 in terms of the new API v1.1 calls. So the "custom" v1.0 API is actually keeping the same interface/methods as the v1.0 API but inside its implementation it is actually making calls to the new API v1.1 methods.

So the large app can be then compiled and linked against the "custom" v1.0 API and the new v1.1 API without any major source code changes.

Is there a term for this practice?

There's a recent example of this happening in Jamie Zawinski's port of XScreenSaver to the iPhone - he re-implemented the OpenGL 1.3 API in terms of the OpenGL ES 1.1 API. In this case, OpenGL 1.3 represents the "old" API and OpenGL ES 1.1 represents the "new" API.

  • 2
    API 1.0 would effectively become an adapter of API 1.1? If so, there's your answer... – yannis Jun 20 '12 at 2:41
  • 2
    You need a name for your patterns book. How about Back to the Future Adapter? – psr Jun 20 '12 at 3:05

If I understand you right, you'd be implementing the adapter pattern to isolate the API calls from the rest of your application. So when the time came to switch from v1.0 to v1.1, you'd just modify your API wrapper implementation to make different calls and the rest of your application wouldn't know or care.

So your application structure would look something like this:

.----------.       .-------------.       .----------.
| Your App | ----> | API Wrapper | ----> | API v1.0 |
'----------'       '-------------'       '----------'
                              |          .----------.
                              `--------> | API v1.1 |
| improve this answer | |
  • Posting my comment as an answer? Well done! ;P – yannis Jun 20 '12 at 2:42
  • +1 To the comment and the answer. So this is where Anna gets all her extra rep from ;) – Gyan aka Gary Buyn Jun 20 '12 at 2:44
  • @YannisRizos The timestamps are almost on my side. :P – Adam Lear Jun 20 '12 at 2:45
  • 29 seconds too late is still too late! – yannis Jun 20 '12 at 2:46
  • 1
    @YannisRizos c'mon other guys repost her comments as an answer, why can't Anna do the same? :) – gnat Jun 20 '12 at 5:01

Thanks to Anna Lear and Yannis Rizos for their answer, i.e. that the API 1.0 has effectively become an adaptor for API 1.1.

I just wanted to put forward a more specific answer. In my case the API 1.0 has retained the same public interface, so the application doesn't need to change. The only thing that has changed is the internal implementation of the API 1.0 itself - it now has a dependency on the new API 1.1. So instead of "porting the application" to use API 1.1, we're "porting the API".

Porting an API

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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