TenYears

From APIDesign

Ten years ago, on July 29, 2008, the Practical API Design book was published. Isn't that a date to remember and celebrate? Yeah, may be it is. It certainly deserves at least a little note. Many things has changed over the last ten years...

The language that I used for most of the examples, Java, is no longer as popular as it used to be. It is no longer taught at basic university courses. It is no longer the choice of those who want to use good technology with all its three essential components (coolness, time to market and Cost of Ownership). Does that mean TheAPIBook content is no longer valid? Not that all! I always expected Java to evolve into something different - the language was just a tool - thus the core ideas still remain fresh and useful.

REST has grown way stronger in the last decade. When TheAPIBook was written, the term API was still reserved to various types of API (Protocols, FilesLayout, Dependencies, CLI, and of course signatures). The REST was just one of the types. I realized things has changed in 2014 when I received a question: How does the API economy impacts the APIDesign? At that moment it was clear, the term API has been kidnapped by the REST guys. When regular people hear API they first and foremost envision web services! That is upside down, as network communication is just a part of the Art of Building Modern Software, but the expectations have shifted and one has to live with that.

TBD: Types has went and returned back.

I left the source of inspiration of TheAPIBook - I only contribute the NetBeans in my spare time - as a result I had to find another organization to feed me with APIDesign mistakes. It is a strong suply, yet I believe the list of my achievements in the recent years allows one conclusion: It is possible to design an API as a service! I wish the impact of Practical API Design book has been bigger. It is clear there is a lot of people attempting to design an API and it would really help them to avoid inventing the wheel. Many of the Practical API Design observations would help to avoid the mistakes I am seeing all around. But maybe it is not that easy to read, may it is the personalization that counts!

Don't you need a skilled API designer? Don't you want to improve your API Design skills with a funny game-like training? Talkback to me. Actively joining would be the best celebrations of the 10th anniversary of the Practical API Design book!