[cheald]

I would argue that once an API is published and put into use, it becomes a list of facts about the interfaces in the program. You cannot change an API without undermining its entire purpose. In that sense, it is factual, in that the API class paths and signatures are effectively routing information between a client program and the API implementation. They describe the means by which you give data to a library and give data back.

An API may be entirely as functional (though not necessarily as usable) if no creative thought or effort goes into it. You could have all your API methods be called api1(...), api2(...) and still have them function. Creativity and skill are a very useful component in making APIs, but I would argue that they are not requisite, as evidenced by the dearth of uncreative APIs created by unskilled programmers who have still managed to create libraries and services that we use on a daily basis.

[jimmyvanhalen]

According to Joshua Block, Google's Chief Java Architect. (slide 62 and 63)

“I find it very rewarding to design great APIs and have people come to me years later and say, wow, you know, the collections framework changed my life.”

"API design is a noble and rewarding craft"

"API design is tough"