I will get back to APIs in a moment. For now, let us assume that we were in the car manufacturing business and we would like to build a new car … What would we have to do?
- We find out, how the consumer would want to use the new car.
- We design the car, so it fits into the portfolio of different models that our company sells – sports cars, vans and trucks.
- We choose the architectural style, i.e. if the car uses a diesel engine, hybrid engine or a fully electric engine.
- We design a blueprint of the car according to the consumer’s needs and wants. We simulate components of the car and build a prototype.
- We select the component suppliers of our car parts, zr/>
- Finally, we configure the assembly line for putting all the car parts together efficiently.
Could work. And what would the corresponding steps be, when building an API?
- We find out, how the majority of consumers would want to use the new API.
- We design the API, so it fits into the portfolio of different APIs that our company offers.
- We choose the architectural style, i.e. if the API applies a REST, RPC or SOAP style.
- We design a blueprint of the API using an API description language, such as RAML or Swagger. We simulate the API and build a prototype of the API.
- We select the API platform, which provides the reusable building blocks for the APIs.
- Finally, we use a generative API methodology to develop APIs efficiently. Of course, you can only use the generative techniques as far as possible, at some point you might still need to write some code.
All too often, we are tempted to jump into action directly. This is especially true, when building something, which is supposed to be as simple as an API.
Having a guideline for building APIs is extremely helpful, especially when building enterprise APIs. Such a guideline can be provided by a methodology, which is tightly connected to the architecture.
If you need to build APIs for the enterprise, you might be interested in my new book on API architecture and API methodology.