Repository navigation
max results for /stations/:id/departures #3
Description
Activity
Is there a reason why the
departuresendpoint does not support the results parameter to limit the number of results?Yes: The upstream API (HAFAS) only supports requesting by the period of time to return departures for. This correlates roughly with the number of returned departures, so you can query for e.g. 30 minutes and take the first 10 results.
There's only one way for
bvg-restto guarantee a specific number of departures: Send multiple requests to HAFAS, collecting enough results. This can potentially take a significantly longer time, which is why it's currently not implemented. I would be a cool optional feature though!Thank you for the clarification
Do you think this is worth implementing in
bvg-rest(or rather in the underlyinghafas-rest-api)?Well, I'm not sure. I thought about implementing the workaround with multiple requests myself in my user code. The funny thing is that I initially didn't think about the
resultsparameter in the same way you do. I came to think about it because I actually got more results than expected, not fewer. My case should be easy to solve on the API end (although it is of course also easy to solve in my user code). Anyway, when the user code only needs N results max, we could easily support it and save some network traffic and save some processing on the user side. I was really thinking of theresultsparameter as an equivalent oflimitin SQL, which also doesn't guarantee any minimum number of results, just that there won't be more than the specified limit. Maybe it would even be a good idea to call it that way, if it makes the meaning more clear. For example in the/stations/nearbycase, with a very large value forresultsit will also not return as many results, say 1M :)We could name it e.g.
maxResults. What do you think?Sounds good to me
Is there a reason why the
endpoint does not support the
resultsparameter to limit the number of results?I'd find it quite useful to have this when I want to display just the next N trips at a station. Of course I can do it in the calling code, but still I think it would also make sense to have the classic parameter for limiting the number of results...