It's probably worth considering PATCH instead of PUT for updating the table.
http://restcookbook.com/HTTP%20Methods/patch/ You could also think about using JSON-patch to describe the requested update. It provides fine-grained update semantics: https://tools.ietf.org/html/rfc6902 Tim On Fri, Jan 5, 2018 at 5:50 PM Eric K <[email protected]> wrote: > We've been discussing generic push drivers for Congress for quite a while. > Finally sketching out something concrete and looking for some preliminary > feedback. Below are sample interactions with a proposed generic push > driver. A generic push driver could be used to receive push updates from > vitrage, monasca, and many other sources. > > 1. creating a datasource: > > congress datasource create generic_push_driver vitrage --config schema=' > { > "tables":[ > { > "name":"alarms", > "columns":[ > "id", > "name", > "state", > "severity", > ] > } > ] > } > ' > > 2. Update an entire table: > > PUT '/v1/data-sources/vitrage/tables/alarms' with body: > { > "rows":[ > { > "id":"1-1", > "name":"name1", > "state":"active", > "severity":1 > }, > [ > "1-2", > "name2", > "active", > 2 > ] > ] > } > Note that a row can be either a {} or [] > > > 3. perform differential update: > > PUT '/v1/data-sources/vitrage/tables/alarms' with body: > { > "addrows":[ > { > "id":"1-1", > "name":"name1", > "state":"active", > "severity":1 > }, > [ > "1-2", > "name2", > "active", > 2 > ] > ] > } > > OR > > { > "deleterows":[ > { > "id":"1-1", > "name":"name1", > "state":"active", > "severity":1 > }, > [ > "1-2", > "name2", > "active", > 2 > ] > ] > } > > Note 1: we may allow 'rows', 'addrows', and 'deleterows' to be used > together with some well defined semantics. Alternatively we may mandate > that each request can have only one of the three pieces. > > Note 2: we leave it as the responsibility of the sender to send and > confirm the requests for differential updates in correct order. We could > add sequencing in future work. >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
