On which code (productCode or productId or even another) can an OSDM consumer build product specific functionality?

[ralfbayer-db]

We assumed initally that productId is a stable code which can be used to base any product specific logic/functionality/configuration upon in a OSDM consumer system.

However this doesn't seem to hold for all OSDM providers.

How does this agree with the fact that there is a product masterdata endpoint - how useful is that with unstable productIDs?

[schlpbch]

The product.code is stable, but also the product.id must be stable during a booking flow. Needs a discussion with @nixxus1030.

Discuss whether we need GET /products/{product-code}.

[nixxus1030]

Hi all, the product.code is stable. The product.id should be stable within one booking process indeed, but not from one booking to another or when reopening the booking some time later

GET /products/{product.code} is not bulletproof (at least from where we look at it) because the product is always from a specific context:

• in the offer phase, as distributors, we source as much info as possible from the provider offers. Most providers onlyconditions in the context of a specific offer so the product conditions we provide are also only applicable to that specific offer

[CGantert345]

Proposal:

stable products: id = /products/12345

new endpoint for stable product: get /products/productCode+issuing-date

[nixxus1030]

The proposal for me is

• product.code is always stable
• product.id is stable within the context of an offer or a booking

we could add a standalone stable endpoint, which would then be GET /products/?productCode=<productCode>&idType=<code>&issueingDate=\<date\>&travelDate=\<date\>

This call then would lack any context-related information. dates could be optional, in which case today would be assumed for both dates.

If this is ok, we can proceed and add the GETter. It should be documented too.

[schlpbch]

@nixxus1030 provides a PR.