Matt Davis

Linking to #437, in which the current language was added and we had some related discussion. To clarify something from there, the 404 status is not meant to be used...

Along the lines of "I have very little confidence that any two implementations of it will agree with each other", I also had that thought and would love to have...

For me at Populus I'm most interested in the range of dates that an API will return 200 responses. For snow days or seasonal hiatuses I think the APIs can...

I like that "provider manifest" idea, I don't think this kind of system metadata belongs in the trips and status changes endpoints.

In addition to reporting, being able to specify accessible vehicle types would help with policies that mandate certain levels of fleets be accessible vehicles. See some reporting on such vehicles...

I meant that an `adaptive_scooter` vehicle type or some other vehicle type metadata would be necessary for a city to create an MDS policy mandating a certain number or percentage...

I like the idea of a `last_heard_from_time` in the /vehicles endpoint, I think we'd get a lot of utility out of that. But how I imagine the heartbeat working is...

The issue with only putting a heartbeat into the /vehicles endpoint is that it's not part of the historical record available via the status changes endpoint. It can tell us...

I tried to put together a summary of the options we've discussed and the pros/cons of each: # Heartbeats in /vehicles Providers could put a `last_heard_from_time` in the MDS /vehicles...

Oh nice @schnuerle, I'm not sure I realized we'd made that clarification into the spec. I updated the point above. In practice, I'm not sure we often see removed vehicles...