The MAXON API is the new API that is used to build and extend Cinema 4D. In the long run it will replace the classic API. While in some aspects the MAXON API is quite different than the classic API, in other aspects it is quite comparable.
The classic API is defined in the cinema.framework. This API is especially written to give access to internal data and functionality. The classes and functions of cinema.framework are not the actual, internal classes but wrapper functions that may or may not reflect the complete internal functionality.
In contrast, the MAXON API is organized in multiple frameworks. The MAXON API is based on interfaces (see Interface Basics). These interfaces are the exact same interfaces as used internally by MAXON developers.
Classic API plugins are typically based on a specific plugin class e.g. ObjectData. A plugin implementation must be registered with a specific function like RegisterObjectPlugin(). Such a Register function must be called in the context of PluginStart() which is typically defined in the main.cpp file. A plugin must be registered using a unique ID obtained from plugincafe.com
With the MAXON API mostly all components are based on interfaces. A new plugin implementation is created by implementing such an interface. Basically all interfaces can be re-implemented by a third-party developer. A custom implementation is registered using the unified registry system (see Registries). A main.cpp file is no longer needed. The plugin is identified using a custom ID based on a reverse domain notation name.
Cinema 4D does not know any dependencies between classic API plugins. A plugin must handle C4DMSG_PRIORITY to set its own priority.
With the MAXON API, module dependencies are automatically detected by analyzing include statements.
The classic API includes multiple different event and message systems (see Core Messages Manual, NodeData::Message() Manual, GUI and Interaction Messages Manual).
The MAXON API provides the unified observer system to subscribe to certain events (see Observables).
Many elements of the classic API are based on C4DAtom. In the MAXON API, most interfaces are based on maxon::ObjectInterface.
In the classic API, GeListNode is the base of all elements that can be organized in a list or tree. In the MAXON API this is done using maxon::HierarchyObjectInterface.
See GeListNode Manual and HierarchyObjectInterface Manual.
GeData and BaseContainer are generic data containers that can store all data types of the classic API. The corresponding counter-parts of the MAXON API are maxon::Data and maxon::DataDictionaryInterface.
See GeData Manual, BaseContainer Manual, Data Manual, DataDictionary Manual.
The classic String class is based on the new maxon::String class. The classic API handles file names with Filename; the MAXON API with the maxon::Url class. To convert maxon::Url to Filename and vice versa use MaxonConvert().
maxon::Vector and maxon::Matrix act similar like their classic predecessors.
See String Manual (Classic), String Manual, Filename Manual, Url Manual, Vector Manual (Classic), Vectors, Matrix Manual (Classic) and Matrices.
Is is possible to create new classic data types based on CustomDataType. New MAXON API data types are declared with MAXON_DATATYPE.
A NodeData based plugin can define how its data is written to file by implementing NodeData::Write() and NodeData::Read().
Any MAXON API type can implement DescribeIO() to define how internal data should be written to file.
See NodeData::Read() / NodeData::Write() Manual and DescribeIO Manual.
The Description class defines parameter description of classic API elements.
The maxon::DataDescriptionInterface of the MAXON API allows interfaces to handle data description.
See Description Manual and Data Descriptions.