If learning to write a
program is learning how to
walk, learning to program in an
API (Application Program Interface) is like learning how to climb a
mountain. It's much harder, more
confusing, has many dead ends, and you have to basically do it a certain way.
In a high-level view, most APIs
force upon the user a certain type of executable
strategy.
MacOS and
Windows (for example) basically want you to adhere to some kind of event handling
architecture, whether the events are referred to as "events" (Macintosh), or they are referred to as "messages" (Windows). Most modern API sets make it easier for you to retrieve information from the various
components, and to make it easier to make the operating system perform certain tasks at your command.
For instance, it would be quite difficult to communitcate with the
GDI engine in Windows, if the GDI and bitmap functions were not provided. The sequence of calls, to strange (even stranger) APIs, and weird
dll exports would make programming on the
platform incredibly difficult. Thus it makes programming for a moderm operating system much easier.
A huge
disadvantage of
API programming is that sometimes, API calls will fail. More actually, this will happen a lot of times, and detecting their failurs can be
difficult, as you are relying on someone else's code. In my experience, most APIs have a good deal of the bugs worked out of them, and that what you are passing into them (or prevailing system conditions:
low memory, out of
handles, disk
timeout, can't find a file) are the cause of such
problems. There are also error handling
functions, but again, that goes back to learning to program a certain way to get the results you want on other operating systems.
A good
API should be the following things (none are all these things, but a few have most):
- Powerful: An API should have the power to accomplish tasks in the system with as few calls as possible. The programmer wants to be able to accomplish his or her stuff, not to spend all their lives manipulating system calls to get a component of their code working, and still remain:
- Flexible: The API should be extensible, easily workable, and should give the programmer any avenue on which to go down. You should also be able to write and publish your own APIs for other third parties to use.
- Decent Performance: The API should have a reasonable expectation of performance for what you would normally be using it for. If an API is too slow and sluggish, it's not worth using.
- Well Documented: Programmers are smart people. Nothing is too hard to learn with decent documentation. A lot of APIs fail to meet this expectation. We didn't write the vendor's code, and therefore don't inherently know how it works. Even with clever API names such as CreateCompatibleBitmap(), we still don't know exactly how it functions.
- Debuggable: Without being able to debug an API call, and to see where it went wrong, you are in deep mud a lot of times. What are you going to do? Well most APIs should have either the source code (in an open source model), or retail / debug builds, along with the symbols for those builds. Along with error checking and generation functions, this will help your code be better, stronger, and more robust.
- Stable: One should NEVER crash inside of an API function, no matter what you pass in it (unless the method is well published; for instance, the string functions are arguable). This does not help a programmer debug at all, if the program crashes at a certain point. Instability happens, but it should be handled appropriately with an API.
A few examples of commonly used APIs are: