Open philipashlock opened 11 years ago
An alternative approach to this is to provide an update pingback.
Suggestion from Struan Donald
A way to tell a system we're posting a service request to what our internal id was and where it could send updates to and then the update mechanism discussed earlier could be used to post back updates.
http://lists.open311.org/groups/discuss/messages/topic/q3PmGKEqwUwkGMX9I4BCe
An early system architecture diagram also suggested the use of PubSubHubbub as a way to disseminate updates: http://wiki.open311.org/Open311.org_Draft_Spec#System_Architecture
This was added as an extension for the Open311 implementation in chicago (http://dev.cityofchicago.org/docs/api/service_requests) and updated on the v2.1 draft page (http://wiki.open311.org/GeoReport_v2.1_Draft#Optional_Arguments_3) as the '''updated_before''' and '''updated_after''' parameters
A renewed discussion has also come up on the discussion list at http://lists.open311.org/groups/discuss/messages/topic/3xXKjqm1FlTzwmbLjrbk8V
Reported by Benton:
We wanted to make a proposal to the group for a modification (or addition) to GET Service Requests. When using the GET Service Requests method to query the current status of multiple requests, it would be helpful to retrieve requests by updated_datetime. This would eliminate the need to parse a large record sets to compare status in systems that are replicating records to a second location.
We propose either switching the requested_datetime in the spec to use updated_datetime or add a flag to specify which.