Purchaser verbs are inconsistent

[nixxus1030]

The verbs for the purchaser are inconsistent, making it a half-baked resource: we have a get and a patch as if it was a resource, but no post.

we should either have a proper post so that it becomes completely a resource, or remove the patch and get, make the purchaser a data structure and make it accessible via patch booking. Note the former (adding a post) is non-breaking while the latter is

Right now some parties are trying to create a purchaser using a patch purchaser, which is from a REST standpoint a big no-no

[jspetrak]

@nixxus1030 It is not a long ago since we removed ID from the purchaser. I think we head towards Purchasers being modified from patch booking endpoint. Or just highlight that purchaser always exist for booking, and therefore patch is the correct way to modify it, but the creation can't be trigerred from the client side.

[CGantert345]

For GDPR reasons the purchaser exists only within a booking, not as a resource on its own (same as for passengers). The patch is essentially a patch of the booking with the limited scope of adding/changing the purchaser data structure of the booking.

[nixxus1030]

if we don't want purchaser to be a subresources (you are correct @CGantert345 , it cannot be a resource. However it could be a subresource, which exactly matches what you state - that it only exists within the context of the booking, url would be like booking/id/purchaser) and not make a post purchaser, then we either

• make it completely a data structure remove GET and PATCH verbs (breaking) add the purchaser specification in the patch booking request OR
• make purchaserSpecifications mandatory in post booking, so we ensure there is always a purchaser (breaking as well)

Note however that unless we indeed do not want to accept a booking that does not have a purchaser, my preference would be to make of the purchaser an actual subresource, because

• it is a distinct subelement of the booking
• it makes the API (or that part of the API at least) REST consistent again without breaking change

all 3 solutions are REST acceptable - we need to align on which one we prefer. Since it is a bug, we may get way with introducing a breaking change in the fix without major bump version (we did it in the past) - but again the non breaking approach is cleaner IMO

[rolandkla]

The current specs does lead to unharmonised implementations:

• an OSDM provider makes the purchaser functionality mandatory, so it can be patched afterwards
• an OSDM provider creates an empty purchaser when not provided in the booking, so it can be patched afterwards
• an OSDM provider utilises the PATCH as an "upsert". If not existing the patch creates a purchaser and if already existing it updates
• an OSDM provider strictly follows the REST principles and a purchaser cannot be added after booking creation

It would be good to align here to make sure OSDM clients will only have 1 scenario to worry about and not different behaviours.

I think introducing a POST will solve all of the above. This gives the OSDM client the flexibility to update or add a purchaser and prevents the need to provide fake or dummy data during booking time (as this information is often not known upfront).

[schlpbch]

--> Align with Nicloas.