Best practice for product data provision via API server

The provision of product data via REST services is one of the central requirements of modern PIM systems today. To ensure that such interfaces remain viable in the long term and can be expanded without high development costs, an API design is required that is flexible, efficient and cleanly structured.

A central principle here is the dynamic structuring of product data: As requirements for products, attributes, descriptions or marketing content change continuously, the API should not depend on fixed instructions stored in the code. Instead, the structure should be designed in such a way that new features, Text categories or product relationships can be integrated into the API output simply through configuration or a changed database. In this way, the REST services remain stable while the underlying data models grow or change.
The following methods come directly from practice and have already enabled flexible and powerful solutions in many customer projects.

Tailored to the market

In many companies, products are used in different target markets. Regional legal frameworks, different product range strategies or different price and availability models can play a role here.

A modern product API must therefore offer the option of restricting product data by target market so that systems only retrieve the data they actually need.

The situation is similar with language filtering. As product data is often available in multiple languages, the API should make it possible to retrieve specific language versions. This not only serves technical efficiency, but also prevents unnecessary data transfer and storage effort on the client side.

A typical crossbase API filters both market and language-specific. The correlations are created in "Channel Output Management" and each output channel thus receives the appropriate information package: assortments control the scope of articles, country/language combinations control the content. A good example of this is the website of our customer Lamello: https://lamello.com/de/

Only transfer what is necessary

When synchronizing systems, it is also crucial not to have to deliver all product data again every time it is called up. A time-based restriction, for example via a "Last Modified" timestamp, allows only those products to be provided that have been changed since the last retrieval. This not only reduces the volume of data, but also improves the performance of processing, especially for large product inventories and regular retrievals.
Determining such a "delta" only makes sense for very large data quantities. We recommend it to our customers who provide many thousands of products with numerous variants via API for store systems and configurators.

Individual control

To achieve a particularly high level of flexibility, we recommend the use of generic parameters for query and control functions such as paging, filters and sorting. By providing such functions in general rather than individually for each new requirement in the API, the interface can cover a wide range of evaluation and data output scenarios without losing clarity or having to be continuously expanded.
Good coordination with the web developers of the target system, for example the CMS, is necessary here. The search functions of a website in particular benefit from parameterized API queries.

Separate product data and hierarchy

Another important aspect is the separation between product data and product structures.
In this context, product structures are understood to be a hierarchical categorization, such as that required for the navigation of a website. Such structures map categories, subcategories and navigation paths and therefore do not represent the properties of an individual product, but rather the organizational classification. As these categorizations can evolve independently of the product data, they should be provided separately via the API. This enables target systems to systematically build up their navigation or category logics without having to transfer the entire structure again with each product query.

You are probably familiar with this from your everyday life: There are more frequent corrections at the level of a product than in the navigation structure. Incidentally, crossbase makes a clear distinction between the internal data maintenance structure and other structures used for your output channels.

Reduce redundancy with recurring content

Similarly, master data such as multilingual attribute descriptions should be delivered separately from the product data. This information changes comparatively rarely and is used jointly by many products. If they are provided separately and can be retrieved by key, this significantly reduces the size of the individual product responses and simplifies processing on the recipient side.

Another example of master data is value lists that websites use for search forms. It would be a huge effort to read out all possible values of a feature from all products. This is much quicker with a centralized master data retrieval!

Conclusion

A REST-based product data API that takes all of these principles into account will be clear, flexible, efficient and future-proof. It can be extended extremely quickly without having to change existing code, supports integration into a wide range of system landscapes and can easily handle growing databases and increasing requirements.