OpenStack APIs are defined strictly in two forms: a human-readable specification (usually in the form of a developer's guide) and a machine-processable WADL. These specifications define the core actions, capabilities, and media-types of the API. A client can always depend on the availability of this core API and implementers are always required to support it in its entirety. Requiring strict adherence to the core API allows clients to rely upon a minimal level of functionality when interacting with multiple implementations of the same API.
Note that it is quite possible that distinct implementations of an OpenStack API exist. First because API specifications are released under a free license, so anyone may use them to implement a core API. Furthermore, the OpenStack implementations themselves are released under a free license, making it possible to alter the code to create a specialized version. Such a specialized implementation could remain OpenStack-compatible even if it were to implement new features or add new capabilities, but only if it made the changes in a manner that ensures that a client expecting a core API would continue to function normally — this is where extensions come in.
An extension adds capabilities to an API beyond those defined in the core. The introduction of new features, MIME types, actions, states, headers, parameters, and resources can all be accomplished by means of extensions to the core API. In order for extensions to work, the core API must be written in such a manner that it allows for extensibility. Additionally, care should be taken to ensure that extensions defined by different implementers don't clash with one another, that clients can detect the presence of extensions via a standard method, and that there is a clear promotion path at the end of which an extension may become part of a future version of the core API. These actions, rules, and processes together form the extension mechanism. It is important that core APIs adhere to this mechanism in order to ensure compatibility as new extensions are defined. Note also that while a core API may be written to allow for extensibility, the extensions themselves are never part of the core.