Team 2 - Output of endpoints

[edwinvandenbelt]

A small question, with huge impact (please think about this one thoroughly):
Is the output of each endpoint always a (part of) the 'travel package'? (maybe not for the search for offers, this will reply of course offers). But the rest of the operations, it seems to me that they all must return a (part of) travel package. Maybe an additional part, containing things like financial consequences (like the [partial] exchange, or [partial] reimbursements), but these are again offers...

[edwinvandenbelt]

Should we facilitate both 'heavy clients' as 'light-weight clients'? In other words, the output must be configurable (in the call 'includeAllOperationalDetails': boolean)? Of course, the GDPR related stuff should not be included, therefore we should look at the GET /booking aka GET /package, imho.

[CGantert345]

GDPR related stuff must be included if it is needed only. This is not related to a light weight client option. If you have personalised bookings the bookingId itself falls under GDPR.

[oven]

In my opinion, the number of rest calls is more important than the amount of data returned by each call. Each call adds latency, so I think it is better to return more data with each call to limit the number of calls.

I would expect the API to be mostly used by backend systems, not by the actual frontends. Frontends usually are backed by a dedicated backend system that integrates with other systems, prepares data for display and adds functions for the user interaction.

[joachse]

Difficult to balance, but I would also throw in another option for adding additional data.

We could also consider the option of having sub-resources for these additional data such as "OperationalDetails"

Example
GET /package/{id}/operational-details which would result in a list of operational detail for this specific package.

Any thoughts on this @CGantert345, was in considered in OSDM?

[CGantert345]

OSDM uses an embed parameter with predefined "packages", but as said it is not used by implementors, as the complexity added is too high. We should accept that the concept of light weight client is not cost efficient in our environment.

[edwinvandenbelt]

We could make it an 'policy' attribute, thin/fat clients?

[CGantert345]

Offers are not a booking and after sales end points will return offers for the after sales which are not always included in the booking. Some endpoints will return availabilities of seats of on demand services which are also not bookings and some will return tickets. So most likely the majority of end points will not return the booking.

[edwinvandenbelt]

Agree. In the TOMP, we have 2 'formats': one returing a list of offers, and one that returns a package (Booking). The implementor can decide what it returns, it can be a full package (thin clients), but also a package, containing only the modified fields (fat clients). It is up to the implementation right now.