This concept is addressed to developers who want to make use of Intershop's APIs.
There are two main types of API:
This type of API is used to connect to external systems. This can be the integration of an external system, such as a payment service, or it can be the provisioning of services, such as the ICM REST API used to connect to the Rest-based Storefront (PWA).
The main subtypes of Service API are:
A reference of the ICM REST API can be found here:
The creation of new REST resources is described here:
Information about existing backend service interfaces can be found here:
The creation of new service interfaces for a (Managed) Service and implementation is described here: Concept - Managed Service Framework.
This type of API can be used to extend and customize the functionality within the Intershop application server, like modification of existing features or adding of new features.
Internally Commerce Management comprises 3 layers:
Components in each layer can provide a certain set of Java API that can be used for customization and extension. All public API is contained in a Java package named capi or in subpackages of it. All other Java types are internal and must not be used.
The application layer provides additional pipeline extension points and template extension points. They are also treated as public API.
Currently, Commerce Management supports the overloading mechanism for Intershop software artifact types. Overloading may seem convenient at first, but it causes major migration problems in the long run.
Therefore, Intershop does not recommend using the overload mechanism. Instead, use extension points or, if not applicable, copy complete application cartridges to replace the original ones. Also see Overview - Application Framework.
Description | |
---|---|
SEMANTIC | Since ICM 11, this API follows the rules of semantic versioning. The API can be changed in a compatible way in a minor version. Deprecations (annotated with "forRemoval") will be removed in the next major release. |
EXPLICITE | These artifacts have their own lifecycle or version definition. Deprecated versions can only be removed in major product releases. |
Service API (to connect to External Systems) | Customization/Extension API | ||||||
---|---|---|---|---|---|---|---|
Service Consumer (integrate other services) | Service Provider | ||||||
(Managed) Service API | XML Import/Export | Product Data Feeds | REST API | Platform API | Business API | Application API | |
API Life Cycle Rules | SEMANTIC | EXPLICITE | EXPLICITE | EXPLICITE | SEMANTIC | SEMANTIC | SEMANTIC |
Layer | Business | Business | Business | Application | Platform | Business | Application |
Cartridge Types | bc_* | bc_* | bc_* | app_* | pf_* | bc_* | app_* |
API Artifacts | Service interfaces (Java interfaces) meant to be used by the managed service framework | XML schemas used for import and export | Product data feed file formats | All REST resources in capi packages incl. HTTP verbs, response formats, etc. | Java Types in capi packages Java Extension Points | Java Types in capi packages Java Extension Points | Java Extension Points Pipeline Extension Points Template Extension Points Application specific extension/customization mechanisms |
Documentation | Javadoc Confluence/ Knowledge Base for list of deleted artifacts. | Confluence/ Knowledge Base | Confluence/ Knowledge Base | Confluence/ Knowledge Base | Javadoc Extension Point Doc Confluence/ Knowledge Base for list of deleted artifacts Intershop Studio | Javadoc Business Object Extension Doc Extension Point Doc Confluence/ Knowledge Base for list of deleted artifacts Intershop Studio | Javadoc Extension Point Doc Confluence/ Knowledge Base for list of deleted artifacts Intershop Studio |
Migration Tools | Intershop Studio | ETL | Intershop Studio | Intershop Studio | Intershop Studio |