Open NikithShetty opened 2 years ago
Agree with @NikithShetty here. Duplicate ids on both items and fulfillments easily lead to confusion, also this is error-prone in implementations as all references by ids that are duplicated become invalid.
Adding an example of the structure proposed.
{
"items": [
{
"type": "SJT",
"descriptor": {
"name": "Single Journey Ticket",
"code": "SJT"
},
"fulfillment_id": "station-1-to-station-2",
"price": {
"currency": "INR",
"value": "20"
}
},
{
"type": "SJT",
"descriptor": {
"name": "Single Journey Ticket",
"code": "SJT"
},
"fulfillment_id": "station-1-to-station-3",
"price": {
"currency": "INR",
"value": "30"
}
}
],
"fulfillments": [
{
"id": "station-1-to-station-2",
"start": {
"location": {
"id": "station-1"
},
"time": {
"schedule": {
"times": [
"2021-10-15T00:32:19.000Z",
"2021-10-15T01:42:19.000Z",
"2021-10-15T02:57:59.000Z",
]
}
}
},
"end": {
"location": {
"id": "station-2"
},
"time": {
"schedule": {
"times": [
"2021-10-15T00:43:21.000Z",
"2021-10-15T01:53:21.000Z",
"2021-10-15T03:09:01.000Z",
]
}
}
},
"./metro-0_9_3.distance": "12 km"
},
{
"id": "station-1-to-station-3",
"start": {
"location": {
"id": "station-1"
},
"time": {
"schedule": {
"times": [
"2021-10-15T00:32:19.000Z",
"2021-10-15T01:42:19.000Z",
"2021-10-15T02:57:59.000Z"
]
}
}
},
"end": {
"location": {
"id": "station-3"
},
"time": {
"schedule": {
"times": [
"2021-10-15T00:43:21.000Z",
"2021-10-15T01:53:21.000Z",
"2021-10-15T03:09:01.000Z",
]
}
}
},
"./metro-0_9_3.distance": "22 km"
}
]
}
Problem The proposed metro schedule catalog represents items and fulfillments with duplicated objects so as to accommodate same ticket type linked to multiple routes and same route having multiple schedules respectively, which leads to confusion and is not immediately apparent, since
id
is an unique identifier for an object and here we are duplicatingid
for different objects.The idea is that
item
maps to a ticket -Single Journey Ticket
andfulfillment
maps to a route -station1-to-station2
with multiple arrival and departure timings per station. Hereitem
andfulfillment
have 1 to many relationship. However, we also haveprice
value which can differ peritem
-fulfillment
pair which causes issue with this form ofitem.id
duplication, since eachitem
object in the catalog can have a unique price.Sample on_search request
Proposed change I understand that there aren't any unique id generated by BPP for these
item
s in the on_search request, and its also not feasible to uniquely generate and track them for search, where the volumes are high and conversion to confirm are lower comparatively.With these in mind, I would propose to represent a ticket as
item.type
which refers to the type of the ticket -Single Journey Ticket
, avoiding the usage ofitem.id
. To confirm a ticket, BAP can senditem.type
andfulfillment.id
as part of confirm API call.For
fulfillment
, we should make use ofschedule
object and support arrival and departure schedules usingfufillments.start.time.schedule
andfulfillment.end.time.schedule
arrays. We can specify that the array elements be ordered andfufillments.start.time.schedule
andfulfillment.end.time.schedule
array elements match to form pairs of arrival and departure time as part of network policy.