The red line through all these pitfalls seems to be the lack of business focus. Also, when it comes to exposing open APIs, this topic is typically seen as a technical project. But in practice it turns out that it triggers many business related questions, like:
- Who will be the consumer of the API?
- What kind of data or service will it provide?
- Which business domain and application will be the source of the API?
- Should the API be specific for one consumer with one goal? Or should it be more generic?
- Is it to expose from one source application or should it compose an aggregation from multiple sources?
- Is the API to be exposed to trusted parties only, or as a public API?
- How many calls and what size payloads do you expect?
- How secure should the API be?
- Does the API expose privacy related data?
- Do the consumers expect / need support?
- What kind of QoS (reliability, traceability, performance, etc.) do the consumers expect / need?
- Will you charge the consumers? If yes, what kind of pricing model will you apply?
- How will you manage version control?
- Have you covered liability with terms and conditions?
All these questions need to be properly answered to make your open API initiatives succeed. In fact, open APIs should be seen as new business services with a new target audience. Your new customers are external developers working for existing customers or partners, or even completely new customers you never new existed. Oh, and by the way, these new customers expect to consume high quality data. So if you haven’t tackled pitfall 4 yet, please think twice before you decide to expose your data to the outside world…