max results for /stations/:id/departures

[sebkur]

Is there a reason why the

GET /stations/:id/departures

endpoint does not support the results parameter 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...

[derhuerst]

Is there a reason why the departures endpoint 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-rest to 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!

[sebkur]

Thank you for the clarification

[derhuerst]

Do you think this is worth implementing in bvg-rest (or rather in the underlying hafas-rest-api)?

[sebkur]

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 results parameter 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 the results parameter as an equivalent of limit in 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/nearby case, with a very large value for results it will also not return as many results, say 1M :)

[derhuerst]

We could name it e.g. maxResults. What do you think?

[sebkur]

Sounds good to me