Diskussion om överlappande APIer och deras IDn

Det skulle vara användbart med en artikel där alla intressenter (trafiklab, sl, mm) beskriver i egna ord vilka roller de tycker sina API har i skenet av andra APIer med överlappande funktionalitet. Till exempel SLs, Resrobots och Trafiklabs APIer som alla kan presentera info om SLs avgångar och hållplatser.




Det skulle också vara användbart att inom ramen för detta ha en diskussion om att leverera inter-API-IDn för objekt för att uppmuntra samverkan mellan dessa APIer på klientsidan. Till exempel, varför kompletterar inte Resrobot eller Trafiklab sin API-data med SL-specifika ID för relevanta objekt? Då kan klienter välja att enkelt erbjuda utökad funktionalitet för de aktörer som är proaktiva och lanserar nya nischade funktioner i sina egna APIer.




Med svar på dessa frågor blir det enklare att navigera bland APIerna och välja bland dem. Om vi till exempel har svart på vitt att det saknas intresse för interoperabilitet mellan APIer så kan vi enklare besluta huruvida vi vill fokusera på en enskild aktör eller på minsta gemensamma nämnare (eftersom det då inte är gångbart med båda samtidigt).




Jag använder till exempel SL Transport och använde förut SL Närliggande hållplatser, och är intresserad av exempelvis svar på frågan varför Resrobots Närliggande hållplatser har i det närmaste identisk anrops- och svarsstruktur – som gjord för att ersätta SLs nedlagda API – men med objekt-ID som inte är kompatibla. Det känns som en missad möjlighet. För mig hade det varit ett självklart val att helt enkelt gå över till att använda Resrobot för Närliggande hållplatser, om de bara hade haft interoperabilitet. Att åstadkomma den på klientsidan är däremot inte lika tilltalande, så då blir frågan istället "ska jag kanske bara skippa SLs APIer helt och hållet framöver?", vilket är synd.

ano

Kommentera eller skriv ett nytt inlägg

Ditt namn och inlägg kan ses av alla. Din e-post visas aldrig publikt.