Right now, journey objects can contain information like departure, arrival, etc. as a shortcut for journey.legs[first].departure or journey.legs[last].arrival.
Since the original idea of FPTF was to allow people to easily write software that works with different APIs "on-the-fly", this imposes a problem. If one API returns data that contains redundant information like this and another doesn't, this practically negates the interchangeability of the two sources (and therefore one of the major benefits in using FPTF). For this reason, it might make sense to agree on one common way to return journey information.
Both @derhuerst and me probably slightly favor not including any redundant information here (forcing people to look directly at the (first and last) legs), since this might prevent some misunderstandings (e.g. when the first/last legs are actually not as important, because they're just "walking" trips).
derhuerst
commented
6 years ago
Right now,
journeyobjects can contain information likedeparture,arrival, etc. as a shortcut forjourney.legs[first].departureorjourney.legs[last].arrival.Since the original idea of FPTF was to allow people to easily write software that works with different APIs "on-the-fly", this imposes a problem. If one API returns data that contains redundant information like this and another doesn't, this practically negates the interchangeability of the two sources (and therefore one of the major benefits in using FPTF). For this reason, it might make sense to agree on one common way to return
journeyinformation.Both @derhuerst and me probably slightly favor not including any redundant information here (forcing people to look directly at the (first and last) legs), since this might prevent some misunderstandings (e.g. when the first/last legs are actually not as important, because they're just "walking" trips).
Opinions? Other proposals?