RAD APIs

A RAD API is the starting point for designing a new RAD component. An API consists of a collection of other subsidiary components: derived types and interfaces. APIs are versioned so that a client can specify which API version to use.

The users of the RAD APIs belong to two categories. administrators and developers. Accommodating both categories of consumers within one interface is difficult. Administrators require task-based APIs which match directly onto well-understood and defined administrative activities. Developers require detailed, operation-based interfaces which may be aggregated to better support unusual or niche administrative activities.

For any given subsystem, you can view existing command-line utilities (CLIs) and libraries (APIs) as expressions of the rad APIs. The CLIs represent the task-based administrative interfaces and the APIs represent the operation-based developer interfaces. The goal of using a RAD module is to provide interfaces that address the lowest-level objectives of the target audience. If you are targeting administrators (task-based), your goal could translate to matching existing CLIs. If you are targeting developers, your goal could mean significantly less aggregation of the lower-level APIs.

An API name defines the namespace, which identifies objects to the clients. APIs can have versions and a single RAD instance is capable of offering different major versions of APIs to different clients. RAD modules are a grouping of interfaces, events, methods, and properties which enable a user to interact with a subsystem.

When exposing the elements of a subsystem, you should consider how existing functions can be grouped together to form an interface. Imperative languages such as C tend to pass structures as the first argument to functions. The structures provide a clear indication of where to group functions into APIs.