New converged booking attempt

[adelcasse]

Following our discussions today, I made a new attempt on converged booking to merge PR #6 and PR #5.

During discussions in the end of the meeting with @ccyrille and previous discussions with Mobility by Colas, I figured out there might by 3 flows instead of 2 (1 with booking by API, and 2 flows to retrieve booking information with booking by deeplink) :

The booking by API flow is quite clear as it is always initiated by the MaaS

For the booking by deeplink, there were 2 considerations :

• The need to have a direct link between a journey on the MaaS side and the booking on the operator side to be able to reconcile journeys data for example for multimodal journeys. Even without "Connect".
• The need for an operator to send back data to the MaaS independently of the journey, linked to the connect mechanism, like explained by Cyrille with the use case of IDFM (report back every booking, not only the one after the deeplink redirection).

For these 2 flows, I described distinct processes :

• For the journey to journey connection, the MaaS should first pre-initiate the booking like in the booking by API flow, and then send the user to the operator platform using the deeplink. This removes the need of booking parameters in the search endpoints and makes it simpler than the initial proposition of @osarrat (we might, in this case, remove the PUT /bookings introduced by Olivier ? I kept that for the moment)
• I created a new endpoint for a webhook to send push notifications on booking events from the operator side to the MaaS. This would be as simple as possible in the "upsert" way proposed by Cyrille in PR WIP - Add spec proposal for POST and PATCH booking information #5 ...

[tcroiset]

Hi @adelcasse, thanks for this proposal.

The deeplink case with an additional pre-initialization call looks a bit complicated for me and not necessary as the booking_events looks enough to synchronize all the bookings, but maybe I miss some constraints.

I also added 2 minor comments

[tcroiset]

Not described. Did you mean passengerToken ?

[tcroiset]

I think this might be missing:

 driver:
    $ref: '#/components/schemas/User'

[ccyrille]

Hi @adelcasse,

Thank you for this proposal.

Sorry but I don't understand, all the Interact don't seem to have something to do with the need of sending booking information back to the MaaS platform.

We have two separate PR to describe the "Booking" / Interact (#6) and the "Feed" / Webhooks (#5) use-cases. Why not keep them separated so we don't mix everything's up?

Needs expressed by the people from Mobility by Colas seem quite specific and maybe they can fit in the Interact. If so, it should be added to PR#6. Or in a completely separated PR so we can measure what supporting this specific need implies / have a dedicated conversation about it.

I will add elements to PR#5 to support expressed needs & feedbacks (including the ones that appear here, from @tcroiset & me).

[ccyrille]

From its structure, this is not an "event" but a "booking". Calling it an event will bring confusion, particularly about the id that must be the unique identifier of the booking.

[ccyrille]

Having a subsequent bookingId brings even more confusion (vs previous id).

[adelcasse]

@tcroiset @ccyrille this was a proof of concept of my idea I wrote quickly after our last meeting. Of course we can change order of paragraphs, etc... Mayve event change the structuration of all of while looking at how it could integrate with the description of the standard proposed in #12 ?

@tcroiset The difference between the webhook and the API + deeplink is the nature of the link to the MaaS

• For the webhook : it allows to send data from the operator to the MaaS in a way not directly related to a journey in the MaaS. The webhook could even be used for users that did not come from the MaaS, if he initiated an OpenID Connect on the operator side. Anyway, it was requested by Mobility by Colas to be able to link a booking on the operator side to a concrete journey on the MaaS to be able to reconciliate bookings from different mobility modes (for example "parking + carpool"). This is not handled by the webhook flow as the operatir initiating the webhook call doesn't know the journey ID on the MaaS side. It also doesn't allow to send back booking information to the MaaS without de Connect. It has other benefits as said before on the other side and is indeed legitimate
• For the API + deeplink : as the MaaS initiates the booking flow before sending to the deeplink, the MaaS and the operator share their mutual journey IDs. Once in the carpoolink app, this booking evolves and the MaaS is notified, without even the need to have an "openID connect" on the operator side. It's in my opinion a different use case that is important. It is just useful for a booking arriving just after a search on the Maas. It doesn't handle sending back informations later from the carpooling operator on other carpools made bu the user with the app. It is complementary to the other flows, inbetween the booking by API flow and the deeplink one.