NS geeft 'reisadvies'-api vrij

De Nederlandse Spoorwegen hebben hun api vrijgegeven. Daardoor kunnen ontwikkelaars applicaties maken die gebruikmaken van gegevens van de NS, zoals vertrektijden, storingen en de locatie van stations.

De NS heeft wel een maximum ingesteld voor het aantal requests dat mag worden gedaan: 50.000 per dag, zo blijkt uit de documentatie. "Respecteer de servercapaciteit van NS; probeer goed om te gaan met de capaciteit die u geboden wordt. Als NS misbruik vermoedt, kunt u direct worden afgesloten", zo schrijft de vervoerder. Ontwikkelaars moeten toegang vragen tot de api om er gebruik van te kunnen maken.

Deze week ontdekte een ontwikkelaar al hoe hij toegang kon krijgen tot gegevens uit de api; de eigen applicatie van de NS bleek de url aan te spreken en inloggegevens onversleuteld te versturen. Andere ontwikkelaars maakten applicaties door de gegevens van de mobiele site van de NS te plukken. Het is onbekend of die ontwikkelaars nu overgaan op gegevens uit de api.

Reacties (70)

[FriXion]

Ik begrijp niet helemaal wat het voordeel is om de api te gebruiken t.o.v. de oude methode. Kan iemand dit uitleggen?

[mddd]

Voorheen vroeg je op de achtergrond informatie op van de mobiele site van de NS. Een app deed dus eigenlijk alsof hij een gebruiker was die de mobiele site bezocht. En uit het antwoord dat dan terug kwam, plukte de app de juiste stukjes informatie.

Hieraan kleven een aantal belangrijke nadelen:

- Als de NS de opbouw / layout van de mobiele site verandert, kan het zijn dat je app opeens niet meer werkt. Voorbeeld: als je app zoekt naar een div-element dat 'resultaat' heet, en dat element heet opeens 'result' dan is het de vraag of je de informatie nog kunt vinden.

- Een html-pagina bevat meer informatie dan enkel de reis-data. Een webservice stuurt als het goed is de informatie zo beknopt mogelijk door. Dat scheelt dus kilobytes. Iets wat belangrijk is als je je info over een brakke 3g-verbinding ophaalt.

[Mellow Jack]

- Een html-pagina bevat meer informatie dan enkel de reis-data. Een webservice stuurt als het goed is de informatie zo beknopt mogelijk door. Dat scheelt dus kilobytes. Iets wat belangrijk is als je je info over een brakke 3g-verbinding ophaalt.

Dit klopt natuurlijk niet helemaal (klopt wel natuurlijk alleen het 3g stukje niet). Ze halen deze gegevens niet realtime van de NS Site.
Ze "pikken" bergen informatie in 1 x en stoppen dat in een lokale database. In deze database stoppen ze vaak ook nog eens de gegevens van bijv Connexions om een overzicht te krijgen.

Dit kan je dus heel gemakkelijk publiceren naar mobiele telefoons of wat dan ook (iets wat bijv 9292ov.nl al doet)

Je eerste Argument is mij laatst toevallig nog overkomen toen ik 15.000 product plaatjes wilde downloaden vanaf een website vrij irritant... Ze hadden exact mijn eerste referentie punt aangepast waardoor het ik hele script opnieuw moet uitvinden (geen documentatie)

Note: De app van de NS werkt wel ideaal... Je kan de vertragingen per minuut uitlezen. Vermoed alleen dat dit niet mogelijk zal worden via de API (aangezien die 50k request dan wel heel snel gehaald worden)

[Reactie gewijzigd door Mellow Jack op 22 juli 2024 17:22]

[mddd]

Ze halen deze gegevens niet realtime van de NS Site. Ze "pikken" bergen informatie in 1 x en stoppen dat in een lokale database.

Ik kan me dat niet voorstellen. Dan zou je dus ALLE reizen van ALLE stations in Nederland vooraf moeten ophalen?? Dat lukt je nooit. Veel te veel mogelijkheden. Bovendien heb je dan geen actuele spoorwijzigingen, vertragingen e.d.

Volgens mij is het echt wel zo dat als jij intikt 'Amsterdam naar Utrecht' dat hij op dat moment naar NS gaat om te vragen hoe de reisschema's zijn van Amsterdam naar Utrecht.

[i-chat]

in principe natuurlijk niet, want je hebt ook gewoon de standaard tijden etc.
de vertragingen van 5 minuten zul je idd beter kunnen negeren, maar je kunt je prima afvragen hoeveel treinen er per dag rijden. lees: van begin tot eind is één trein, ongeacht het aantal stops. als je zo'n opvraag actie dus cashed lees:

trein 232663 vertraging 20min dan weet je dat elke route ongeacht van waar naar waar. die over dat traject wil, hier last mee gaat krijgen.

dus als je slim bent vraag je bij de ns vooral treinen op en niet zozeer routes...

[mddd]

En HOE vraag je die treinen op? De API heeft geen 'vraag alle treinen op' mogelijkheid, enkel 'vraag een advies op'.

Daarbij is het schema van de NS veel te ingewikkeld om op die manier zelf even na te bootsen. Treinen veranderen van nummer, worden gesplitst of samengevoegd, enzovoort. Dit is echt te complex om zelf te gaan interpreteren en dan een advies te geven.

Als je me niet gelooft, vergelijk dan de output van een app zoals Trein eens met de NS site. Dan zul je zien dat het precies matcht qua aangeboden informatie en dat is niet toevallig, beide baseren zich immers op dezelfde actuele NS informatie.

[MarcoC]

Ik vraag me af hoe Trein precies werkt eigenlijk. Wat me opviel toen ik nog de eerste generatie iPhone had (zonder 3G dus) was dat deze app echt enorm snel was. Vaak binnen enkele seconden waren de actuele vertrektijden ververst. Dit spreekt jouw redenering tegen dat Trein enkel de website van de NS parset.

Iemand een idee?

[mddd]

Ik denk dat dat komt omdat de netwerken toen nog niet zo vol zaten.

Vraag het Dennis die de app gemaakt heeft. Het haalt alles gewoon van de NS site hoor. Er zijn op een gegeven moment zelfs updates van die app geweest omdat de NS de mobiele site had aangepast.

[djiwie]

Welke 'oude' methode bedoel je? Een API zoals NS die nu heeft vrijgegeven is voor ontwikkelaars erg handig omdat ze dan de rauwe data kunnen opvragen en verwerken in een applicatie. Bijvoorbeeld: je maakt een app die de route van een trein intekent op een kaart. Met de API kun je dan alle tussenstations opvragen en de coördinaten van die stations.

Apps als Trein werken als een soort custom browser: ze halen de gewone website op, strippen alle data daaruit en verwerken die dan in een eigen interface. Dat is erg omslachtig: meer dataverkeer en de app werkt niet meer als NS haar website aanpast. Deze API geeft XML-berichten terug in een gedocumenteerd formaat. Betrouwbaarder dus en minder dataverkeer/processing time.

[majoh]

Als je gegevens van de site afplukt, en misschien automatisch door scipts of zo te laten doen, dan loopt het verkeer naar de site hoger op dan waarschijnlijk verwacht is, en kan daardoor problematisch worden.

Daarnaast sturen services veel minder informatie door dan complete html pagina's, dus is er minder netwerk verkeer.

En een service api kan apart ge'sized' worden, zodat deze beter afgestemd kan worden op het gebruik.

[bartvb]

Aantal voordelen. Bij de 'oude methode' haalt een app of service op de achtergrond HTML pagina's op bij de NS en daaruit worden de gegevens geëxtraheerd. Hierbij komt flink wat overbodige informatie mee, krijg je niet perse de informatie terug die je nodig hebt, het is een hoop werk om deze informatie uit de HTML te halen en als de NS een klein dingetje verandert aan de site dan is je applicatie waarschijnlijk stuk of onbetrouwbaar.

Met een API voorkom je al die problemen, je kan de NS exact vragen wat je wilt, je krijgt waarschijnlijk sneller antwoord en de antwoorden blijven hetzelfde. Verder is het ook veel makkelijker in het gebruik dan form submissions nabouwen en informatie tussen een hoop HTML uit peuteren.

Maar super dat de NS deze informatie nu beschikbaar maakt! Toe Trein.app net uit was leek het erop dat ze het liefst op hun eigen data bleven zitten, om de een of andere reden zijn ze nu toch over stag gegaan. Super!

Edit: spuit 11

[Reactie gewijzigd door bartvb op 22 juli 2024 17:22]

[Referix]

Ik vraag me af hoe de App 'trein' dit dan al die tijd gedaan heeft.

[Caelorum]

Screenscrapen

[watercoolertje]

Een officiele API is maar 1 van de vele manieren natuurlijk, de HTML ophalen en alle waardes die je wilt er uit halen kan bijv ook. Of misschien is er wel een RSS-feeds beschikbaar...

[Anoniem: 225842]

Via de mobiele versie van NS, zo doet de TreinTijden van Android het ook.

http://m.ns.nl/planner.action

[Reactie gewijzigd door Anoniem: 225842 op 22 juli 2024 17:22]

[EricEric752]

Erg netjes van NS. Bedrijven hebben meestal de neiging om dit soort dingen niet te delen of actief tegen te werken. Na het eerdere bericht dat een app ontwikkelaar toegang had gekregen tot de api had ik eigenlijk verwacht dat NS dit zou negeren of zelfs zou dreigen met een rechtzaak. Niets van dit alles. Hulde voor NS.

[mokie]

Valt wel mee hoor; kan het bericht nu even niet vinden, maar de NS heeft in het verleden een felle juridische strijd uitgevochten met de bedenker van de bekende treintijden-lite app. Deze app haalde idd ook gevevens van de NS site, maar was op een of andere manier beter en sneller op de hoogte van actuele vertrektijden en vertragingen dan de officiële NS-app.
De NS beschouwde deze data namelijk als eigendom en wilde dat de bedenker van de treintijden app ophield met het aanbieden hiervan.. Kennelijk zijn ze hier nu vanaf gestapt.

[AW_Bos]

En terecht, op deze data zit ook geen auteursrecht volgens Arnoud Engelfriet.

[Eguna]

Ik vermoed dat het voorheen lukte met HTTP requests, als het ware was de app een kleine browser die delen van de ns.nl website uitpluiste en de resultaten toonde. Een API zal natuurlijk stukken handiger en effecienter zijn!

[Wallie]

Kan de NMBS in België een voorbeeld aan nemen

[Anoniem: 402568]

Ik heb ook ff wat gemaakt

http://spoorvertraging.appspot.com/

[DJMaze]

"De NS heeft wel een maximum ingesteld voor het aantal requests dat mag worden gedaan: 50.000 per dag"
Daar kom je toch nooit aan als eind gebruiker?

[mddd]

Het aantal requests zal wel zijn per partij die een API licentie krijgt. Dus simpel gezegd per app. En alle gebruikers van een app samen kunnen gemakkelijk meer dan 50.000 requests doen, zeker als je bedenkt dat voor 1 reisadvies misschien meerdere requests nodig zijn.

[Mellow Jack]

Zouden ze het niet gewoon mappen in een database? Ik kan mij best voorstellen dat ze hun eigen database op bijv Zondag updaten (wat betekend enorm veel requests) zodat ze tijdens het dagelijkse gebruik alleen de vreemdheden (zoals vertragingen) hoeven te verwerken in de DB

Oooh oops ik zie net dat het niet gebruikt mag worden voor commerciële doelstellingen dan zal mijn verhaaltje wel niet opgaan en blijven de sites gewoon gebruik maken van het opvragen van HTML files

[Reactie gewijzigd door Mellow Jack op 22 juli 2024 17:22]

[mddd]

Dat denk ik niet. Om dat goed te kunnen doen, zou je onderhand zelf de NS moeten zijn, zoveel kennis is er voor nodig. Want stel dat je een advies opvraagt van Amsterdam naar Utrecht en er is halverwege een versperring. Hoe geef je dan een advies? Dat lukt je nooit. Terwijl de NS zelf je dan gewoon een alternatieve route (over Den Haag ofzo) kan voorstellen.

[tricksel]

Precies, dat is toch ook de bedoeling? Men wil niet dat je er commercieel gebruik van gaat maken. Zelfde geldt voor bijv. vele diensten van Google. Als eindgebruiker kom je nooit aan het maximum, maar wel als je er "rare" dingen mee wilt doen.

[Caelorum]

Moet je eens een mobiele applicatie maken.
5K mensen per dag die de applicatie gebruiken.
Applicatie maak meer dan 10x een request .
En dan zit je al aan je limiet. Zo mogen wel een soort van aanvraag systeem maken voor het verkrijgen van ruimere request limieten.

[Precision]

Dan sla je ze toch zelf op in een databank en maak je de app hierdoor al dan niet betalend. Je kunt immers garanderen dat je altijd de juiste up-to-date info (mits deze correct is bij de NS en zij geen problemen hebben) hebt

[Caelorum]

Dat kan ja en is ook iets wat ik overweeg. Echter brengt dat wel een aanmerkelijke extra investering in zowel tijd als geld met zich mee.
In een eerste versie zal dat iig in mijn applicatie daarom nog niet in zitten.

[mddd]

Leg me eens uit wat de voordelen daarvan zijn. Het is een enorme klus en je zult nooit dezelfde accurate resultaten halen als met de info die je live van NS haalt. Plus dat je een server-side component draaiend moet houden anders werkt je app niet. En van een app wordt verwacht dat die altijd up to date info geeft. Op het moment dat een trein vertraagd is moet je dat direct in beeld brengen. Dat lukt je niet want kleine vertragingen zitten niet eens in de lijst van storingen en werkzaamheden.

Petje af als het je lukt, maar ik zie vooral een grote stapel met mogelijkheden voor problemen.

[Caelorum]

Deijst met werkzaamheden, de lijst met stations en de lijst met prijzen kan je best cachen op je webserver. De duur ervan is iets waar je aan zal moeten sleutelen.
Wat je dan eigenlijk doet is de betrouwbaarheid van de dienst vergroten (omdat er een max 50K requests is) en iets aan actualiteit inleveren.
Voor een kleine applicatie is dat zeer waarschijnlijk een beetje overkil.
Overigens zaken als reisadvies zal je nooit fatsoenlijk kunnen cachen omdat deze vrijwel altijd uniek zijn.

[mddd]

Ja, dat is logisch en staat ook in de API beschrijving van NS zelf.

Stations komen er niet zo vaak bij dus als je die 1x per dag ophaalt is het zat. En werkzaamheden elke paar minuten verversen (1 api call) en dan via je eigen server doorzetten, okee.

Maar dat zijn allemaal de simpele dingen. Het gaat natuurlijk om de reisinfo want dat is het complexe en kun je naar mijn overtuiging nauwelijks op een nuttige manier cachen.

[Caelorum]

Klopt, maar je stelde dat er nauwelijks voordelen zijn. Maar als jij van 1000 api-calls naar 1 api-call kan gaan per dag voor een specifiek iets lijkt me dat toch wel een voordeel. Dat namelijk al weer 2% minder op het totaal beschikbaar en kan het vershcil zijn tussen wel het eind van de maand halen en niet.

[mddd]

Ik zei dat er nauwelijks voordelen zijn, waarbij ik er vanuit ging dat we het over het ophalen van reisinformatie hadden.

Dat je dingen cacht die weinig veranderen, leek mij uberhaupt niet ter discussie staan. Maar misschien ging ik daar wat te gemakkelijk vanuit aangezien ik regelmatig met webservices en caches bezig ben.

Ik vatte de post van Precision ("dan sla je ze toch op in een databank") en jouw reactie daarop dus op als doelend op de reisadviezen. Als ik dat verkeerd aannam, dan mijn excuses daarvoor.

[Dylan93]

Ze hadden ook niet echt veel andere keuzes nadat eerder deze week een ontwikkelaar toegang had gekregen.

[sumac]

Ze hadden wel degelijk keuze. Ze stuurden de login onversleuteld mee. Dat hadden ze eenvoudig aan kunnen passen. Misschien had dat een paar dagen of een week geduurd, maar ze hadden het af kunnen sluiten.

[ASS-Ware]

Ze hadden wel degelijk keuze. Ze stuurden de login onversleuteld mee. Dat hadden ze eenvoudig aan kunnen passen. Misschien had dat een paar dagen of een week geduurd, maar ze hadden het af kunnen sluiten.

Sure, maar dan gaat een slimme jongen die app wel debuggen en kom je alsnog het user id en password tegen.

[Relief2009]

Een api maak je niet voor de lol. ze waren dit al lang van plan.

[XBL]

Hun API bestond voor hun eigen software tools, ik betwijfel of ze echt de boel vrij wilden geven (wellicht op langer termijn). Als ze dat (nog) niet van plan waren, dan kudos voor de NS, het is namelijk een goede reactie.

Even los van de vraag of dit niet een 1 april grap is .

[AW_Bos]

Nee, ik kan bevestigen dat dit geen 1 april grap zou zijn.
Daarvoor is deze te goed opgezet. Het zij behoorlijk stom zijn dat straks opeens 100 sites zie die er gebruik van maken terwijl er opeens '1 april' op het scherm wordt getoverd door een respons van de NS api.

Ik heb het zelf uitgetest en het ziet er voortreffelijk uit. Alle data klopt voor zover.

[Caelorum]

op 1-12-2010 was al bekend dat ze het wilden gaan doen, nadat ze eerder hadden gezegd dat ze er niets in zagen.

[Wiebbe]

Dit limiet geld ook voor de ontwikkelaar. Je schrijft je in als ontwikkelaar, krijgt inlog gegevens en die moet je in je App verwerken.

Stel dat ik met TreinTijden de Api zou gebruiken dan mogen 20.000 gebruikers maar 2 1/2 keer per gebruiken vertrektijden of een reis opvragen. Dat is natuurlijk heeeeeeeeel erg weinig./

[GORby]

Bij misbruik behouden ze het recht om ertegen op te treden en de API key in te trekken. Waarschijnlijk gaat dat vooral zijn wanneer er veel requests vanop 1 IP komen, wat erop zou wijzen dat iemand die gegevens gaat ophalen voor andere zaken dan privé-gebruik.

Wanneer er veel requests zijn, maar het aantal requests per IP blijft beperkt (wat wijst op veel gebruikers van een goed geschreven app), dan hoop ik niet dat ze daar moeilijk over doen.

[Caelorum]

Daarnaast zou je als je lullig wilt doen ook meerdere keren een api kunnen aanvragen en dan rouleren..

[MaffeMaarten]

Of van je gebruikers eisen (misschien automatiseren via de app) dat ze hun eigen inloggegevens aanvragen bij de NS.

Zoiezo is het voor de ns ongustig als ze dit te streng gaan verbieden, want dan vallen de ontwikkelaars terug op website-scrapen, en dat kost de NS veel meer data.

[Dr C]

Hoe werd dat voorheen gedaan dan, want er zijn al wel wat apps voor de iphone die deze gegevens gebruiken ('Trein' bijvoorbeeld).

[Stoffel]

Waarschijnlijk direct van de site gescraped. Als je het als mens kunt lezen kun je ook een app schrijven die de data eruit vist.