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
(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 export
s 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 handle
s, 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: