'. '

3SidesToEveryAPI

From APIDesign

(Difference between revisions)
Jump to: navigation, search
(New page: Not many things we know have just a single meaning. Often, depending on the point of view, there can be multiple truthful ways of describing properties of the same objec...)
Line 1: Line 1:
Not many things we know have just a single meaning. Often, depending on the point of view, there can be multiple [[3SidesOfAnyAPI|truthful ways]] of describing properties of the same object. Throughout the [[TheAPIBook|Practical API Design]] book I claimed beauty is not important, however after reading [[User:PetrHejl|Petr Hejl]]'s recent blog post [[Blogs:PetrHejl:BeautyMatters|Beauty Matters]], I can't do anything else then nod in agreement. Did I change my mind? Do I see why beauty matters in [[API]] design now? Well, maybe. But more importantly [[User:PetrHejl|Petr]] made me realize that term [[API]] is not a single indivisible entity, it can probably have at least [[3SidesOfAnyAPI|three different meanings]].
Not many things we know have just a single meaning. Often, depending on the point of view, there can be multiple [[3SidesOfAnyAPI|truthful ways]] of describing properties of the same object. Throughout the [[TheAPIBook|Practical API Design]] book I claimed beauty is not important, however after reading [[User:PetrHejl|Petr Hejl]]'s recent blog post [[Blogs:PetrHejl:BeautyMatters|Beauty Matters]], I can't do anything else then nod in agreement. Did I change my mind? Do I see why beauty matters in [[API]] design now? Well, maybe. But more importantly [[User:PetrHejl|Petr]] made me realize that term [[API]] is not a single indivisible entity, it can probably have at least [[3SidesOfAnyAPI|three different meanings]].
 +
 +
TBD: Geometrical point is indivisible, always the same. Line, divisible, but always same. API, is interface, a line, between at least two things, as such it should be as clear line!?
 +
 +
== Yours ==
 +
 +
TBD: What clients see. A lot like Petr's view. API should allow its users to write beautiful code. We all want beauty, deeply inside us since Greese days. Beauty is important here, as it increases acceptance, and happiness, simplifies maintenance.
 +
 +
== Mine ==
 +
 +
TBD: What the maintainer sees. Keep in mind there is one maintainer and many users. A nice facade can hide complete mess. Beware, abstractions leak. If "unmaintainability" leaks, your users will be quite upset.
 +
 +
== The Truth ==
 +
 +
TBD: The role of the API of its own, without an observer. Can it make its every observer satisfied? It is "interface" - can it really separate its observers? Can it separate the client from the maintainer? Or client from the provider? A lot about freedom to change (each observer, without interfering with others) evolution aspects.
 +
 +
== The Role of Beauty ==
 +
 +
Important on the "Yours"/Clients (Petr's point). Sacrify yourself if you are producers of an API (TheAPIBook's point).
 +
 +
TBD: Mention tribute to [[wikipedia::III_Sides_to_Every_Story]].
 +
TBD: Category:APITypes

Revision as of 20:52, 22 November 2008

Not many things we know have just a single meaning. Often, depending on the point of view, there can be multiple truthful ways of describing properties of the same object. Throughout the Practical API Design book I claimed beauty is not important, however after reading Petr Hejl's recent blog post Beauty Matters, I can't do anything else then nod in agreement. Did I change my mind? Do I see why beauty matters in API design now? Well, maybe. But more importantly Petr made me realize that term API is not a single indivisible entity, it can probably have at least three different meanings.

TBD: Geometrical point is indivisible, always the same. Line, divisible, but always same. API, is interface, a line, between at least two things, as such it should be as clear line!?

Contents

Yours

TBD: What clients see. A lot like Petr's view. API should allow its users to write beautiful code. We all want beauty, deeply inside us since Greese days. Beauty is important here, as it increases acceptance, and happiness, simplifies maintenance.

Mine

TBD: What the maintainer sees. Keep in mind there is one maintainer and many users. A nice facade can hide complete mess. Beware, abstractions leak. If "unmaintainability" leaks, your users will be quite upset.

The Truth

TBD: The role of the API of its own, without an observer. Can it make its every observer satisfied? It is "interface" - can it really separate its observers? Can it separate the client from the maintainer? Or client from the provider? A lot about freedom to change (each observer, without interfering with others) evolution aspects.

The Role of Beauty

Important on the "Yours"/Clients (Petr's point). Sacrify yourself if you are producers of an API (TheAPIBook's point).

TBD: Mention tribute to wikipedia::III_Sides_to_Every_Story. TBD: Category:APITypes

Personal tools
buy