SL Transport: Vissa fält är oanvändbara med befintlig svarsstruktur
Nu heter ju API:et *SL* Transport vilket kanske på sätt och vis antyder att ”den enda transport_authority som någonsin figurerar här i är Storstockholms Lokaltrafik”, men jag tycker det är ganska olustigt att göra detta antagande för ett API vars dokumentation ens nämner fält som ”transport_authority” – om det redan är underförstått, varför existerar då ett sådant fält? Med detta sagt, till själva problemet:
Vissa fält som servas är tekniskt sett oanvändbara: departure.journey.id har beskrivningen ”Unique identifier of a journey within a line and a transport authority”, vilket betyder att den endast kan spela en användbar roll ifall man även vet 1) vilken linje denna journey avser, samt 2) vet vilken transport authority denna journey avser. Problemet uppstår när detta journey.id inte levereras med dessa båda pusselbitar, vilket är fallet här:
Den LineReference en Departure levereras med saknar transport authority, som inte heller går att finna någon annanstans i en Departure. Utan detta går det inte att använda journey.id (eller ens line.id) korrekt, och fältet blir tekniskt sett överflödigt. Jag kan nu t.ex. inte implementera en jämförelsefunktion mellan två Departure som svarar på huruvida båda syftar till samma Journey. Jag hävdar att detta omintetgör poängen med att få dessa id levererade över huvud taget.
Man kan ju argumentera att jag borde kunna få reda på transport authority genom att använda lineReference.id för att få ett helt Line-objekt (med något slags anrop, föreställer jag mig), men då tar man inte hänsyn till LineReference.id:s beskrivning som även den gör sitt fält intetsägande om man inte känner till transport authority: ”Unique identifier of a line within a transport authority”. Att få reda på transport authority har nu blivit beroende av att redan veta transport authority. Om API:et ska vara sin egna data trogen så bör den rimligtvis avslå alla sorters begäran som anger Line.id men som inte samtidigt anger transport authority.
Jag ser inte hur detta kan lösas snyggt på något annat sätt än att transport_authority blir ett fält i LineReference, eller att alla id blir oberoende av transport authority (låter mindre realistiskt…) Att t.ex. göra bara LineReference.id oberoende av transport authority skulle som bäst tvinga mig att göra en massa helt onödiga anrop för att få tag på riktiga Line-objekt (för att kunna använda mig av DepartureJourney.id), så jag skulle inte kalla den lösningen för snygg.
För mig innebär detta att jag tillsvidare kommer behöva tilldela alla LineReference en artificiell transport authority som alltid representerar SL, i väntan på att det fältet läggs till.
Vissa fält som servas är tekniskt sett oanvändbara: departure.journey.id har beskrivningen ”Unique identifier of a journey within a line and a transport authority”, vilket betyder att den endast kan spela en användbar roll ifall man även vet 1) vilken linje denna journey avser, samt 2) vet vilken transport authority denna journey avser. Problemet uppstår när detta journey.id inte levereras med dessa båda pusselbitar, vilket är fallet här:
Den LineReference en Departure levereras med saknar transport authority, som inte heller går att finna någon annanstans i en Departure. Utan detta går det inte att använda journey.id (eller ens line.id) korrekt, och fältet blir tekniskt sett överflödigt. Jag kan nu t.ex. inte implementera en jämförelsefunktion mellan två Departure som svarar på huruvida båda syftar till samma Journey. Jag hävdar att detta omintetgör poängen med att få dessa id levererade över huvud taget.
Man kan ju argumentera att jag borde kunna få reda på transport authority genom att använda lineReference.id för att få ett helt Line-objekt (med något slags anrop, föreställer jag mig), men då tar man inte hänsyn till LineReference.id:s beskrivning som även den gör sitt fält intetsägande om man inte känner till transport authority: ”Unique identifier of a line within a transport authority”. Att få reda på transport authority har nu blivit beroende av att redan veta transport authority. Om API:et ska vara sin egna data trogen så bör den rimligtvis avslå alla sorters begäran som anger Line.id men som inte samtidigt anger transport authority.
Jag ser inte hur detta kan lösas snyggt på något annat sätt än att transport_authority blir ett fält i LineReference, eller att alla id blir oberoende av transport authority (låter mindre realistiskt…) Att t.ex. göra bara LineReference.id oberoende av transport authority skulle som bäst tvinga mig att göra en massa helt onödiga anrop för att få tag på riktiga Line-objekt (för att kunna använda mig av DepartureJourney.id), så jag skulle inte kalla den lösningen för snygg.
För mig innebär detta att jag tillsvidare kommer behöva tilldela alla LineReference en artificiell transport authority som alltid representerar SL, i väntan på att det fältet läggs till.
Följ inlägget
1
följare
Ber om ursäkt om sen återkoppling, men det stämmer som du säger. Jag kopplar vidare detta till SL.
Hälsningar,
Bert
Vi har nu fått bekräftelse att SL kommer lägga till TransportAuthority i svarsdata. Det finns dock inget tidsestimat på detta.
Hälsningar,
Bert