Simplify the requests

[CraigglesO]

I recently added GBFS to a gis-tools project I've been working on.

I like this project and I do want to admit I probably have perhaps a weaker perception of the larger goal, but I figured I'd try to present this idea incase it's not outside the realm of possibility.

One thing I found slightly frustrating was that to access all the data, it requires multiple fetches for each JSON and may even require an additional fetch for the manifest. This kind of waterfalls down from gbfs.json.

My argument is that for most of the feeds (or maybe all of them), if you combined each schema, you'd still end up with a fairly small json file to ship out.

The idea then is that the gbfs.json COULD, if desired from the one hosting the data, ship all of the data in a single request.

The idea is that gbfs.json can come in two forms, one for a combination of everything in it, or its current form as pointers to the other available data.

[mplsmitch]

I get that it's more work for consumers to fetch individual files but there's a reason it's structured as it is. GBFS defines a mix of data, some of which rarely if ever changes, like the name of a system, it's city & contact information etc, while other data changes very frequently, like vehicle availability and vehicle location. Each of the endpoints has been designed with this in mind. For example, station_information contains data that rarely changes, whereas station_status changes constantly. TTLs for these endpoints should be set accordingly so that data that rarely changes is rarely fetched.

My argument is that for most of the feeds (or maybe all of them), if you combined each schema, you'd still end up with a fairly small json file to ship out.

We've already got feeds that are so large that they often time out before loading the full endpoint, here's an example:
https://api-public.odpt.org/api/v4/gbfs/hellocycling/station_status.json

[CraigglesO]

Thanks for the speedy response!

This actually brings attention to the other point I never really made but is pretty important:

This spec doesn't value compression enough. JSON data compresses really well. That link you provided, when gzip compressed is only 83kB!!!!!

At the risk of sounding a little combative, the counterpoint is that merging all the data should be an optional design. Meaning if it's known by the owner of the endpoint that it will never grow too large than a single request could improve the number of calls, and allows the requester to have all the facts and not worry about missing monthly or yearly updates / bug (spelling) fixes since all the data is there to parse each time.