Udostępnij za pośrednictwem

Two really different types of API

  • Artykuł

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.

Comments

  • Anonymous
    December 20, 2005
    Gareth is basically right: the MetaEdit+ API supports operations on the models (e.g. add an object), and on the tool (e.g. open a diagram), but not low level platform primitive calls. Of course, the code you write to do the API calls can do what it likes in terms of low level platform primitive calls.

    I'm sure Gareth's right in principal that there are low-level platform primitive operations that could be useful in the API itself, in certain situations. Can people provide some examples? Only when we actually have concrete examples can we start to support them well: otherwise we're at the stage where we say "well, people might want to do anything!", and that tends to mean we don't yet really know what this area is all about (and that's not a dig at Microsoft).

    Again, this question is sufficiently interesting that there's more in my blog entry:
    http://www.metacase.com/blogs/stevek/blogView?showComments=true&entry=3312572564

    Steve