The central premise of the DODS data delivery architecture is that it is possible to categorize many APIs used to store/access scientific data as following closely with the UNIX file system paradigm of open, read and close9. Furthermore, it is assumed that any state information used by the API can be stored locally in the client process and does not need to be retained by the data server.
In order to build the client library for a particular API, it is necessary to re-implement that API so that it uses data that can be acquired from the DODS data access protocol rather than the files or other data store it was originally design to use. The client library must also maintain the illusion of a connection (state) for each open data object (typically a file) even though no such connection actually exists (because the DAP is a stateless protocol).
To accomplish these tasks with a minimum of difficulty, it is useful to divide the API to be re-implemented in five types of functions: