|
|
|
| Authored by: Anonymous on Friday, May 04 2012 @ 03:03 PM EDT |
Please allow me refine that definition just a little:
1. Entity name.
2. Argument order.
3. Argument types. (if any)
4. Return type. (if any)
I would have added "if any" to argument order, but I'm willing to
count an empty set). ;)
Also, that information is the API - any writing down of that information in any
particular form is documentation (you can call it a spec if you;re using it that
way).[ Reply to This | Parent | # ]
|
| |
| Authored by: PJ on Friday, May 04 2012 @ 03:37 PM EDT |
Except it's not a definition. That's the
documentation.
Or am I getting confused again?[ Reply to This | Parent | # ]
|
| |
| Authored by: Anonymous on Friday, May 04 2012 @ 03:43 PM EDT |
Each individual API is a *concept*, its an idea, like a math equation. The
things you listed are just the expression of part of the idea. Other parts
include things like "when you call this function, you must also call this
other function later when you're done". The API is the entire contract for
correctly using the functionality; both the low-level technical details which
MUST be correct to even connect the pieces together, and the high-level details
about how to use those pieces correctly to do what you want.
Correct usage of library functionality requires the programmers to know the
rules for its proper usage. Those rules are part of its API.
"Application Programming Interface" taken literally, means
"everything you need to connect your application to this useful
black-box-library-thing".
Anyways my main point in the grandparent post you are responding to, was that
the topic of APIs is by no means a simple topic, even though lots of *experts*
seem to think for some reason that it is. Like most things in CS, the deeper
you go down the rabbit hole the more intricate things get.[ Reply to This | Parent | # ]
|
|
|
|
|
