'. '

TenYears

From APIDesign

(Difference between revisions)
Jump to: navigation, search
Current revision (06:48, 29 July 2018) (edit) (undo)
 
(27 intermediate revisions not shown.)
Line 1: Line 1:
-
Ten years ago, on July 29, 2008, [[TheAPIBook]] was published. Isn't that a date to remember and celebrate? Yeah, may be it is. It certainly deserves at least a little note. Thus let me write one...
+
[[TenYears|Ten years]] ago, on July 29, 2008, the [[TheAPIBook|Practical API Design]] book was published. Isn't that a date to remember and celebrate? Yeah, it certainly deserves at least a little note. Many things has changed over the last [[TenYears|ten years]]...
-
[[TBD]]
+
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]] advises are no longer valid? Not that all! [[I]] always expected [[Java]] to evolve into something different - the language was just a tool - the core ideas still remain valid.
+
[[REST]] has grown way stronger in the [[TenYears|last decade]]. When [[TheAPIBook]] was written, the term [[API]] was still reserved to all [[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'' impact the [[APIDesign]]? At that moment it was clear, the term [[API]] had 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.
-
Kidnapped by REST guys. [[TBD]].
+
[[ClarityOfTypes|Types]] went away and returned back. For a while it seemed that types were heading to unimportance with the decline of [[Java]]. It is true that the runtime characteristics of dynamic languages like [[JavaScript]] got on par over [[TenYears|the years]]. Yet, it seems the types are striking back: [[TypeScript]], [[Kotlin]], etc. show that for certain tasks (like designing an [[API]]) having a type is an advantage. While [[I]] am able to design an [[API]] in a dynamic language, having types makes it all more convenient and alike to advises described in [[TheAPIBook]].
-
[[TwoYearsWithTruffle]] - designing [[API]] as a service.
+
I left the source of inspiration of [[TheAPIBook]] - I only contribute to the [[NetBeans]] [[Apache]] project in my spare time - as a result I had to find [[OracleLabs|another organization]] to feed me with [[APIDesign]] mistakes. It is a [[MidlifeCrisis|strong suply]], yet I believe the list of my [[TwoYearsWithTruffle|achievements in the recent years]] allows one conclusion: It is possible to design an [[API]] as a service! I wish the impact of the [[TheAPIBook|Practical API Design]] book has been bigger: It is clear there is a lot of people struggling to design an [[API]] and it would really help them to avoid inventing the wheel. Many of the [[TheAPIBook|Practical API Design]] observations would help to avoid the mistakes [[I]] am [[MidlifeCrisis|seeing all around]], but maybe it is [[TheAPIBook|not that easy to read]], maybe it is the [[Talkback|personalization]] that counts!
-
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 an entertaining game-like [[Using_Games_to_Improve_API_Design_Skills|training]]? [[Talkback]] to [[I|me]]. Actively joining would be the best celebration of the 10th anniversary of the [[TheAPIBook|Practical API Design]] book!
-
 
+
-
Don't you need a skilled [[API]] designer? Don't you want to improve your [[API Design]] skills with a funny game-like [[Using_Games_to_Improve_API_Design_Skills|training]]? [[Talkback]] to [[me]]. That'd be the best way to celebrate the 10th anniversary of [[TheAPIBook]]!
+

Current revision

Ten years ago, on July 29, 2008, the Practical API Design book was published. Isn't that a date to remember and celebrate? Yeah, 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 all 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 impact the APIDesign? At that moment it was clear, the term API had 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.

Types went away and returned back. For a while it seemed that types were heading to unimportance with the decline of Java. It is true that the runtime characteristics of dynamic languages like JavaScript got on par over the years. Yet, it seems the types are striking back: TypeScript, Kotlin, etc. show that for certain tasks (like designing an API) having a type is an advantage. While I am able to design an API in a dynamic language, having types makes it all more convenient and alike to advises described in TheAPIBook.

I left the source of inspiration of TheAPIBook - I only contribute to the NetBeans Apache project 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 the Practical API Design book has been bigger: It is clear there is a lot of people struggling 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, maybe 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 an entertaining game-like training? Talkback to me. Actively joining would be the best celebration of the 10th anniversary of the Practical API Design book!

Personal tools
buy