- Coupling 2.1 Types and modes (design, deployment, runtime) 2.2 Temporal - bound to a past or future state 2.3 Transitive - bound to something through you (tunneled) 2.4 Relational - one thing required to be used with another thing 2.5 Expressive - bound to the granularity of expression provided 2.6 Synchronous - two or more things that have to happen simultaneously 2.7 Logical - bound to logic 2.8 Domain - bound to your domain context 2.9 Presentation - driven by your server
What makes good API design?
Lately I've been trying to concisely explain what makes good design from an API space without completely disengaging the audience. I've been spending a lot of my effort trying to find ways to communicate this without any fancy jargon, and so far the best I have is this. Good API design is about clarity of purpose with a low barrier to entry. Each of these points is rooted in extremely strong computer science fundamentals and traditions, but more importantly these are innately understood by the reader.
To explore this a bit, lets look at some sports equipment: a soccer ball and a bowling ball.
Now, lets assume we have never before seen or participated in either of these sports. The purpose of both seems a bit unclear, but if you pick them up you can begin to get an understanding of their properties. The soccer ball is obviously lighter and consistent, while the much heavier bowling ball has three strangly placed holes. I could kick the soccer ball, or perhaps throw it, but as the ball is relatively hard and too large to comfortably carry in one hand, its probably for kicking. The bowling ball however, is certainly not for kicking, nor is it obviously for throwing either. Yet on further inspection it seems there is a rather comfortable way to carry the ball with the center two fingers and thumb which allows relatively high levels of control over the ball.