If you want to know why an existing IS is not a good API, you should read my last post on Nordic APIs blog How to Provide APIs With an Existing Information System.

My other self Arnaud Lauret writes about APIs too. This week you can read Should Every Company Consider Providing an API? on Nordic APIs blog.

A few weeks ago I’ve seen an interesting flock of tweets initiated by this question:

This question and the tweets that followed put my brain on quite an animated discussion…

When I look at hypermedia media-types and API definition languages I feel that the frontier between data and documentation is becoming thinner as my knowledge of the API world grows and as the API world evolves.

As I was writing my HAMM and ways of API smartness posts, I wanted more. As I was discussing with smart people about APIs, I wanted ever more. I want to delve deeply into the API ways.

An API must be smart to ensure that consumers will want to use it and remain dumb when they consume it.

Hypermedia is not only a conceptual and philosophical subject of interesting and animate debates among the API community, it’s also a concrete solution we can use to cover concrete needs. In this second part of hypermedia API maturity model (HAMM) series I will talk about my own experience to expose two missing (in my humble opinon) notions in common implementations and include these missing links in an updated version of the HAMM.

When we talk about hypermedia for an API, we’re talking about making it discoverable or browsable. Adding hypermedia to an API potentially brings flexibility, loose coupling, better human readability on the fly and even machine readability on the fly. But nowadays, the hypermedia area for APIs is still a work in progress and it can be implemented in many ways leading to different levels of hypermedia-ness.

When you design an API (even an internal/private one) upon an existing back office (to plug a mobile application on it for example), you should take care of one thing: an API is a display, not a window. An API’s purpose is to expose your data and data processing but an API is only a representation and you’re under no obligation to directly expose the crude reality.

Why you must design your private API in english.
Pourquoi vous devez concevoir votre API privée en anglais.
Perché è necessario progettare la vostra API privata in inglese.
Por qué debe diseñar su API privada en Inglés.
Deshalb müssen Sie Ihre private API in Englisch entwerfen.
なぜあなたは英語であなたのプライベートAPIを設計する必要があります.

As you might have guess, this post targets people designing APIs in non english speaking countries. When you design an API there are many little things that you risk to forget or not take into account, especially when this API is private/internal, and later you may bitterly regret it. Choosing a language for your API is one of them.