TenYears
From APIDesign
| Line 3: | Line 3: | ||
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. | 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 [[APITypes|types of API]] ([[Protocols]], [[FilesLayout]], [[Dependencies]], [[CLI]], and of course [[signature]]s). The [[REST]] was just one of the [[APITypes|types]]. I realized things has changed in 2014 | + | [[REST]] has grown way stronger in the [[TenYears|last decade]]. When [[TheAPIBook]] was written, the term [[API]] was still reserved to various [[APITypes|types of API]] ([[Protocols]], [[FilesLayout]], [[Dependencies]], [[CLI]], and of course [[signature]]s). The [[REST]] was just one of the [[APITypes|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. |
[[TwoYearsWithTruffle]] - designing [[API]] as a service. | [[TwoYearsWithTruffle]] - designing [[API]] as a service. | ||
Revision as of 05:55, 29 July 2018
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.
TwoYearsWithTruffle - designing API as a service.
On the other hand, the feeling I described in the MidlifeCrisis essay are still valid. The impact of TheAPIBook should have been bigger. It is clear there are a lot of people attempting to design an API that would benefit from some of TheAPIBook advises.
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. Joining the party would be the best way to celebrate the 10th anniversary of TheAPIBook!
Follow
