LinkedIn Twitter
Founder of We Wire People, Martijn has 15 years experience in the field of Integration, as an Architect working in and for Enterprises. He mainly advises in case of mergers, application rationalization and Cloud / Social Media back-office integration Martijn blogs at martijnlinssen.com

2 responses to “Cloud API’s don’t exist, but become costlier over time”

  1. Mike Amundsen

    I, too, think quite a bit about the *cost* of releasing APIs for distributed network apps (“Web apps” in the pas, “Cloud apps” today, etc.). I work w/ a handful of SaaS providers that are also very focused on the cost/benefits of APIs.

    Over the last several years I have adopted an approach to providing APIs for dist-net apps using the following general guidelines:
    - “No Versions” – there is only one version of the API, do not release v1, v2, etc.
    - “Perpetual Release” – the API MUST have the ability and stability to grow and change over time.
    - “No Sunset” – the public API details released five years ago MUST still work today

    To pull this off, there is a fundamental difference in the way the APIs are designed. They do not rely on RPC (SOAP), Object Graphs, or URIs rules to expose functionality. Instead they rely on Hypermedia (links and forms); even in XML and JSON formats. This means new procedures, objects, and new URI rules can be safely added w/o having to re-write the client code, w/o declaring a new “version” of the API.

    In my experience, this has reduced the cost of maintaining the API (both short and long-term) and reduced the cost of maintaining the clients (long term as initial construction takes a bit more work). More importantly, it has been a big benefit to third-party client creators as they are not required to repeatedly re-write their app as the API grows over time.

    I do not (yet) have real numbers on this work (it takes months/years to accumulate the actual data) and am very interested in efforts to quantity the actual costs in these various appraoches.

  2. Martijn Linssen

    Thank you Mike, very interesting.
    API’s should be seen like letters in an old-fashioned snail-mail envelope: there is no relation between them at all. You just put a different recipient on the envelope and off you go, or you put a different letter in the current one. It is up to agreements explicitly made whether you can use the interface of course…

    SOAP, XML, URI’s and REST have nothing to do with exchanging information and are overly complicated: an interface is just a function – it takes a few values (some optional, some mandatory) as input, and spits out another few as output. Then again most API’s don’t even have a functional description of the inputs and outputs, let alone which ones are optional or mandatory. Twitter would be a perfectly bad example here

    If you want to not force changes, make sure that new functionality is optional at the highest level, and you’ll have technical backwards compatible API’s for centuries to come. However, there must be a sunset; hence my three versions