JaroslavTulach: /* Everything */ - 2022-03-29 03:00:45

Everything

←Older revision Revision as of 03:00, 29 March 2022
Line 6: Line 6:
== Everything ==
== Everything ==
-
The shortest answer to question "What is an [[API]]?" is: ''Everything somebody else can depend on''.
+
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!''

JaroslavTulach: /* Have You Ever Wondered...? */ - 2017-08-27 14:37:08

Have You Ever Wondered...?

←Older revision Revision as of 14:37, 27 August 2017
Line 3: Line 3:
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
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]].
[[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]].
 +
 +
== Everything ==
 +
 +
The shortest answer to question "What is an [[API]]?" is: ''Everything somebody else can depend on''.

JaroslavTulach: /* Have You Ever Wondered...? */ - 2008-11-24 08:41:09

Have You Ever Wondered...?

←Older revision Revision as of 08:41, 24 November 2008
Line 1: Line 1:
== Have You Ever Wondered...? ==
== 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
+
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.
+
[[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]].

JaroslavTulach: /* Have You Ever Wondered...? */ - 2008-08-13 20:59:45

Have You Ever Wondered...?

←Older revision Revision as of 20:59, 13 August 2008
Line 2: Line 2:
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
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
-
[[Determining What Makes a Good API|the chapter 3]] define what it means an API, and explain why and enumerate various types of [[APITypes]]. Then I also looked at the basic criteria to ensure an API is really good.
+
[[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.

JaroslavTulach: /* Have You Ever Wondered...? */ - 2008-08-13 20:58:35

Have You Ever Wondered...?

←Older revision Revision as of 20:58, 13 August 2008
Line 2: Line 2:
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
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
-
this chapter define what it means an API, and explain why and enumerate various types of [[APITypes]]. Then I also looked at the basic criteria to ensure an API is really good.
+
[[Determining What Makes a Good API|the chapter 3]] define what it means an API, and explain why and enumerate various types of [[APITypes]]. Then I also looked at the basic criteria to ensure an API is really good.

JaroslavTulach at 19:57, 2 August 2008 - 2008-08-02 19:57:19

←Older revision Revision as of 19:57, 2 August 2008
Line 1: Line 1:
-
This chapter defines what it means an API, explains why and enumerates various types of [[APITypes]]. It also outlines basic criteria to ensure an API is good.
+
== 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
 +
this chapter define what it means an API, and explain why and enumerate various types of [[APITypes]]. Then I also looked at the basic criteria to ensure an API is really good.

JaroslavTulach at 10:50, 16 June 2008 - 2008-06-16 10:50:57

←Older revision Revision as of 10:50, 16 June 2008
Line 1: Line 1:
-
 
+
This chapter defines what it means an API, explains why and enumerates various types of [[APITypes]]. It also outlines basic criteria to ensure an API is good.

Apidesign: Removing all content from page - 2008-06-14 05:27:35

Removing all content from page

←Older revision Revision as of 05:27, 14 June 2008
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.
 
-
--[[User:AdamDingle|AdamDingle]] 00:09, 28 March 2008 (UTC)
 
-
 
-
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.
 
-
 
-
In fact, there are a few that I think he forgot:
 
-
* Database schemas are sometimes APIs. The last place I worked had a DB for storing logs, and that schema had to be evolved in a compatible way, as other teams were consuming the data in different ways and depended on the schema being stable.
 
-
* WSDL/REST/IDL: perhaps these are too obvious :-)
 
-
* XML Schemas: perhaps this is covered by the more general "files and their contents" section, but I think schemas deserve special mention. After all, we have large standards bodies that do very little beyond nailing down the semantics of XML schemas (e.g. w3.org)
 
-
 
-
* I used this list in '''bc11ce2d561c'''
 
-
--[[User:RichUnger|RichUnger]] Thu Mar 27 21:19:09 PDT 2008
 

JaroslavTulach at 08:29, 5 April 2008 - 2008-04-05 08:29:33

←Older revision Revision as of 08:29, 5 April 2008
Line 10: Line 10:
* XML Schemas: perhaps this is covered by the more general "files and their contents" section, but I think schemas deserve special mention. After all, we have large standards bodies that do very little beyond nailing down the semantics of XML schemas (e.g. w3.org)
* XML Schemas: perhaps this is covered by the more general "files and their contents" section, but I think schemas deserve special mention. After all, we have large standards bodies that do very little beyond nailing down the semantics of XML schemas (e.g. w3.org)
 +
* I used this list in '''bc11ce2d561c'''
--[[User:RichUnger|RichUnger]] Thu Mar 27 21:19:09 PDT 2008
--[[User:RichUnger|RichUnger]] Thu Mar 27 21:19:09 PDT 2008

71.131.199.190 at 04:24, 28 March 2008 - 2008-03-28 04:24:30

←Older revision Revision as of 04:24, 28 March 2008
Line 4: Line 4:
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.
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.
 +
 +
In fact, there are a few that I think he forgot:
 +
* Database schemas are sometimes APIs. The last place I worked had a DB for storing logs, and that schema had to be evolved in a compatible way, as other teams were consuming the data in different ways and depended on the schema being stable.
 +
* WSDL/REST/IDL: perhaps these are too obvious :-)
 +
* XML Schemas: perhaps this is covered by the more general "files and their contents" section, but I think schemas deserve special mention. After all, we have large standards bodies that do very little beyond nailing down the semantics of XML schemas (e.g. w3.org)
--[[User:RichUnger|RichUnger]] Thu Mar 27 21:19:09 PDT 2008
--[[User:RichUnger|RichUnger]] Thu Mar 27 21:19:09 PDT 2008