API Design Tips

First think of the consumer of the API. Think about his likely situation and the problems he's facing. He doesn't want to learn a new abstraction and he doesn't like the fact that your API is going to make him change the design of his program. Design for the benefit of the consumer, not your ease of implementation.

Put your API in a namespace that reflects its function, not your org chart or company brand1

Chose names that describe what each function does and what each type contains or abstracts. Avoid "ProcessData()" disease

The point is to reduce complexity
APIs don't merely implement algorithms that the consumer isn't expected to understand, they also present abstractions that reduce complexity. An FTP library doesn't give the consumer a power they didn't already have, it relieves the consumer of doing the socket programming themselves. If you're wrapping a lower-level API then please don't introduce new problems. Aim for designs that reduce complexity without contributing to it in other ways

Eschew unnecessary side effects

Avoid overwriting the arguments

If you're given a DB or socket connection, assume it's open and never close it yourself

Do not open your own connections if they're not the point of the API's purpose

Use Inversion of Control (IoC) to handle necessary side effects
Let the consumer give you instances of resource managers or event handlers to open auxiliary connections, write to log files, fetch lookup values, interact with the user and so-on

Use events for the bulk of your IoC
Don't force the consumer to create instances of a dozen different resource managers like logging classes, connection pools, name resolution classes etc. before they can call the first function. Raise events so that the consumer can handle only what they need in their circumstance

Use Interfaces everywhere
When events aren't sufficient for your IoC component, or your arguments require a strongly-typed value, then use Interface types--even if you expose concrete implementations as well, and even if you're certain that your concrete implementation is the only kind that will do. Assume your consumer knows what he's doing

Use Interfaces that cover everything you need, but not more and not less
Do you need IList, or just IEnumerable? Or do you actually need IBindingList and are trying to be too modest? If you specify too much you could force the consumer to work harder than necessary, and if you specify too little you risk being passed an insufficient implementation, or make it harder for the consumer to extend your API with a compatible wrapper

Don't make your own gravity
If your target platform has its own crypto primitives, graphics library, transactional memory, XML parser, or whatever--and the point of your API isn't to replace them--then don't reinvent and bind your API to your own implementations, even if you think they're better

return all of your results from the function call
Avoid returning data by setting global variables or writing to files, tables, sockets, etc. Let the consumer decide where the data goes and use aggregate data structures (classes, tuples) if it's necessary to return a success code along with the results

The consumer isn't Sherlock Holmes
If an operation didn't work, or had an unavoidable (and un-IoC-able) side effect, then don't force the consumer to discover this by groping around referenced data structures or other environmental features. Return something other than null or void. Make sure that success is also clearly defined--either return an explicit success code or make sure that the absence of any error can be reasonably construed to mean success

Distinguish types of failures
Did a connection fail because of a timeout, or because the remote host refused the connection, or because the address was invalid, or the login credentials invalid, or because a bird pooped on the switch, or what? Consider exposing and returning an Enum with the types of failures your API can detect

Support optional parameters
Whether by a built-in language feature or via overloads, chose sensible default values or behaviors (timeout values, for example) and give the consumer the option of providing the least you need

true and false are lousy arguments
If you spot the line Filter(widgets, true) somewhere in your code, tell me quick, what does true refer to? Does it mean be case insensitive, or to ignore errors, or to strip the results of blank lines? It's better to create Enums or other data structures that let the consumer's code be expressive and clear, so next time you see it, the line reads Filter(widgets, FilterOptions.IgnoreCase) and everything is clear

Use consistent calling conventionsIf you ask for a filename as the first argument in one of your functions, then stick to that as a convention for any other function that needs a filename. If you arrange argument order randomly you'll force the consumer to memorize the signature for all of your functions, instead of being able to intuit them

Make nouns that encapsulate values, verbs that do stuff with them. Or: Don't Make "Manager" Classes
Avoid creating black-boxes that the consumer has to poke and prod to life

Fail early
Check what the consumer is passing to you and aim to fail before you begin using and modifying resources, especially if those resources don't support rollbacks

Don't be the weak link in the chain
If you use cryptography or handle sensitive data, then have your product audited by a security professional. Use well tested, standardized crypto primitives that have been implemented by security professionals. Be careful to avoid buffer overflow vulnerabulities. Perform strict input validation. Do not invent your own ciphers, and do not implement crypto primitives on your own (unless that's the point), because even the implementation of trusted ciphers can be easily screwed up. Your consumer doesn't want an invisible hole ripped open in their software after they did everything right on their end

One API at a time
Identify a single concern for your API and stick to its scope. This concern could cover a broad category (like graphics, compression, networking), and if it does be sure to break it up into focused namespaces. You probably shouldn't bundle your compression library in the same binary and namespace as your FTP library

One level of abstraction at a time
You may need to build more than one layer of abstraction to get up to the interface you'd like to present to the consumer. Networking now involves stacks 7 levels tall, for example. But keep each level separate, in the sense that each level could be re-used with a different "top" or a different "bottom" each coded to the right Interface

Expose wrappers for value types, but accept strings anywaySome consumers will appreciate a wrapper that strongly types your WidgetSerialNumber, but provide overloads that will also take a string and perform implicit conversion, too. Also favor data types already available on the platform, such as TimeSpans for timeout values instead of integers

Always return the richest type
Following from above: even if the consumer passed an implicitly convertible string, always return the richest type that befits your output. If it's a date or time, return a DateTime value. If it's a number, return an Int, or a Decimal, or your own wrapper type, or whatever fits precisely. Let the consumer convert it back to a string if that's what they want

Implement IClonable, INotifyPropertyChanged, ISerializable and other handy interfaces for your value-wrapping types
Give your types more utility for the consumer so they don't have to marshal values back and forth, just because they want a nice reactive UI or an easy way to save and restore data to disk

Provide flexibility and isolation for configuration
Libraries that link to the application's binary could be configured many ways: in code, as blocks in the application's own config file, or in a separate config file. The consumer will appreciate it if you offered at least the first two. When providing the option to configure the library through a shared config file, make sure to use namespaces or similar mechanism--such as .Net's ConfigurationSection class--to keep yours separate from the rest

Keep your knickers to yourself
Consumers don't need their Intellisense or other inspection tools cluttered up with all your helper classes and utility methods. Make public only what the consumer needs to use your API, and mark everything else as private or internal

Only throw exceptions for the exceptionalExceptions add overhead to the consumer's code and aren't appropriate for reporting expected outcomes. Determine what kinds of errors should be expected for your kind of API and report them as return codes instead of exceptions. A file read/write error would be as common as black squares on a chessboard for a File I/O library, for example, but an out-of-memory fault is incidental to your API and should be thrown as an exception. Also raise exceptions for errors detected in the consumer's code (invalid arguments, unopened connections, out-of-bounds conditions, etc.)

Document the exceptions you throw
Give the consumer the chance to factor exception handling into the design of their program before it's too late to change it

Document how to do what your consumers tend to doRelease 1.0 of your documentation might not contain tutorials and How-Tos for everything your consumers use your API for, but listen to feedback and have a plan to improve the How-Tos chapter of your manual for subsequent releases

Flag deviations from the norm
If your API is a wrapper for a low-level service, and you change the behavior (eg: setting a timeout to zero no longer means wait indefinitely), then document this clear and in bold for those consumers who already know or reference the documentation for the underlying service

Consider shipping your unit tests
They will serve both as a guide to the use of your API, and a framework to reproduce and report bugs that your consumers find in the field

Don't ship an API you haven't used in a useful, working program
For everything that can't be covered here, you will learn whether your API is actually practical and usable by employing it in a program that actually does something useful--not just a unit test or a proof-of-concept, but something that has a UI or interfaces with a real system. That program doesn't necessarily have to be a product that you sell and support, it can be an internal utility, too. Bonus points if the programmer doesn't even work on the API team and therefore provides a fresh perspective.

If you develop the API at the same time you develop the program, you will also have the chance to see and correct mistakes that add unnecessary complexity to the consumer's program, conflicts with the naming scheme of an existing API, or exposes an interface that's unintuitive and confusing. That may be better than all of the above tips combined.

1 - It's okay to use a product name as the root of the namespace. MegaWidgets.Cryptography.DecoderRing.DRCryptoServiceProvider is acceptable, for example.

Other words of wisdom

Michi Henning's essay, referenced at the top, was the inspiration for this collection of tips. He himself was inspired to write it after experiencing the difficulties of using the socket Select() function in the .Net framework, and he passes on some excellent admonitions that bear repeating:

General-purpose APIs should be "policy-free;" special-purpose APIs should be "policy-rich."

APIs should be designed from the perspective of the caller

Good APIs don't pass the buck

A big problem with API documentation is that it is usually written after the API is implemented, and often written by the implementor