Two really different types of API

Steven makes a really interesting reply to my question about API extension in his company's tool.

Firstly he makes the very realistic point that user expectations of a mature tool are that it will have a much wider scope of features than a version one tool - he's quite right there - there's only so much you can or should try to put into any version one product.  There's some interesting commentary on version one products over in the early posts on Chris Pratley's excellent blog.

Steven then notes that their users haven't shown a lot of interest in their API and suggests that this might be because the tool's scope is sufficient for most customers productivity-meeting needs.  He notes that technically, their APIs are web services.

I was momentarily staggered by this - how can you extend a graphical modelling tool that is essentially in-process Windows or Java client code with web services APIs? After all, today's drawing surfaces need to repaint at a frequency that's not conducive to Xml processing - until I suddenly had a moment of clarity.

I'm betting that Steven is talking about what I'm going to call external APIs.

This type of API lets you talk to some piece of software in the terms of the primitives it deals with (obviously for meta-software such as any kind of DSL Tool that is a bit of a loose term).

Let's then talk about a different set of APIs - I'm going to call them internal APIs.

This type of API lets you talk to some piece of software in terms of both the primitives it deals with and the underlying platform primitives it is built on.

If you're building shrink-wrap software, typically you need control down to the level of those internal APIs for a small amount of the time in order to craft the exact feature that's going to give the last ounce of polish to your product.

One aspect of our DSL platform is that we are supporting folks whose sole goal is productivity and also folks who need the last ounce of control to ship killer shrink-wrap.

This certainly gives us a more fine-grained API bias - serving diverse constituencies is always challenging.