Is your feature request related to a problem? Please describe.
Currently, providers can choose their own page size for the /vehicles and /vehicles/status endpoints.
In practice, consumers usually need the complete vehicle list and status data for dashboards, monitoring, and synchronization. Very small page sizes create unnecessary API load. For example, with 4,000 vehicles and a page size of 20, a consumer must make:
2 * (4000 / 20) = 400 API calls
every polling interval. If polling every 30 seconds, this creates excessive traffic for both consumers and providers.
Describe the solution you'd like
Either:
- Remove pagination from
/vehicles and /vehicles/status, since most use cases require the full dataset anyway.
- Or define a minimum page size, for example
1000, and preferably allow consumers to request a page size explicitly via a query parameter.
This would reduce unnecessary API calls while still allowing pagination for very large datasets if needed.
Is this a breaking change?
Yes, for providers that currently use very small page sizes.
However, the expected implementation impact should be limited. In most cases, providers would only need to increase the configured page size or support a consumer-defined page size parameter.
Impacted Spec
provider
Describe alternatives you've considered
Keeping pagination as-is is possible, but it allows inefficient implementations that put unnecessary load on both consumers and providers.
Another option is to add guidance instead of a hard requirement, but that may not solve the issue if providers continue using very small page sizes.
Is your feature request related to a problem? Please describe.
Currently, providers can choose their own page size for the
/vehiclesand/vehicles/statusendpoints.In practice, consumers usually need the complete vehicle list and status data for dashboards, monitoring, and synchronization. Very small page sizes create unnecessary API load. For example, with 4,000 vehicles and a page size of 20, a consumer must make:
2 * (4000 / 20) = 400 API callsevery polling interval. If polling every 30 seconds, this creates excessive traffic for both consumers and providers.
Describe the solution you'd like
Either:
/vehiclesand/vehicles/status, since most use cases require the full dataset anyway.1000, and preferably allow consumers to request a page size explicitly via a query parameter.This would reduce unnecessary API calls while still allowing pagination for very large datasets if needed.
Is this a breaking change?
Yes, for providers that currently use very small page sizes.
However, the expected implementation impact should be limited. In most cases, providers would only need to increase the configured page size or support a consumer-defined page size parameter.
Impacted Spec
providerDescribe alternatives you've considered
Keeping pagination as-is is possible, but it allows inefficient implementations that put unnecessary load on both consumers and providers.
Another option is to add guidance instead of a hard requirement, but that may not solve the issue if providers continue using very small page sizes.