'. '

Determining What Makes a Good API

From APIDesign

(Difference between revisions)
Jump to: navigation, search
Current revision (03:00, 29 March 2022) (edit) (undo)
(Everything)
 
(9 intermediate revisions not shown.)
Line 1: Line 1:
-
In this chapter, it becomes clear that you understand the term API to mean something much broader than most people do: in this book, an API is any kind of interface between software components (or even, I suppose, hardware components) including, say, a network protocol. This is potentially problematic because to most people an API is, well, an API, namely a set of functions or methods available in a library or class. So it's good that you're being so explicit about this. Although your use of this term is broad, I'm actually not sure if there's any better term than "API" to use throughout the book. You could say "interface", meaning a software interface, but that would probably be confusing because the book is Java-oriented and of course the term "interface" has another, more specific meaning in Java. So maybe it's just best to continue to use this term in the way you do, unless other reviewers have any better ideas about this.
+
== Have You Ever Wondered...? ==
-
--[[User:AdamDingle|AdamDingle]] 00:09, 28 March 2008 (UTC)
+
Have you ever searched for the root reason why some of [[API]]s you liked more than others? Are those APIs that you liked the most also those most easily usable? I was thinking about this a lot. First of all I broaden the meaning of the term API and let
 +
[[Determining What Makes a Good API|the chapter 3]] define what it means an [[API]], explain why and enumerate various [[APITypes]]. Then I also look at the basic objective criteria to ensure an API is really good, that it is an example of [[Good Technology]].
-
I think the term API is fine. This is precisely the point Jarda's making, and it's a good one. If people think APIs are just method signatures, they are mistaken. After all, it stands for "Application Programmer Interface". All of Jarda's categories are examples of one developer creating an interface point for an application programmer, right? I think Jarda's goal is to get API developers to think more about how they expose functionality, and how to maintain those interfaces over time.
+
== Everything ==
-
 
+
-
--[[User:RichUnger|RichUnger]] Thu Mar 27 21:19:09 PDT 2008
+
The shortest answer to the question "What is an [[API]]?" is: ''Everything somebody else can depend on''. The emphasis in the previous sentence is being placed on '''can''' - it is not used in the meaning of ''may''! As grandma used to reply: Can I go out? ''Sure, you can. But you may not!''

Current revision

Have You Ever Wondered...?

Have you ever searched for the root reason why some of APIs you liked more than others? Are those APIs that you liked the most also those most easily usable? I was thinking about this a lot. First of all I broaden the meaning of the term API and let the chapter 3 define what it means an API, explain why and enumerate various APITypes. Then I also look at the basic objective criteria to ensure an API is really good, that it is an example of Good Technology.

Everything

The shortest answer to the question "What is an API?" is: Everything somebody else can depend on. The emphasis in the previous sentence is being placed on can - it is not used in the meaning of may! As grandma used to reply: Can I go out? Sure, you can. But you may not!

Personal tools
buy