<div dir="ltr">It's probably worth considering PATCH instead of PUT for updating the table.<div><br></div><div><a href="http://restcookbook.com/HTTP%20Methods/patch/">http://restcookbook.com/HTTP%20Methods/patch/</a><br><div><br></div><div>You could also think about using JSON-patch to describe the requested update. It provides fine-grained update semantics:</div><div><br></div><div><a href="https://tools.ietf.org/html/rfc6902">https://tools.ietf.org/html/rfc6902</a> </div><div><br></div><div>Tim</div><div><br><div class="gmail_quote"><div dir="ltr">On Fri, Jan 5, 2018 at 5:50 PM Eric K <<a href="mailto:ekcs.openstack@gmail.com">ekcs.openstack@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>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.</div><div><br></div><div>1. creating a datasource:</div><div><br></div><div>congress datasource create generic_push_driver vitrage --config schema='</div><div>{</div><div> "tables":[</div><div> {</div><div> "name":"alarms",</div><div> "columns":[</div><div> "id",</div><div> "name",</div><div> "state",</div><div> "severity",</div><div> ]</div><div> }</div><div> ]</div><div>}</div><div>'</div><div><br></div><div>2. Update an entire table:</div><div><br></div><div>PUT '/v1/data-sources/vitrage/tables/alarms' with body:</div><div>{</div><div> "rows":[</div><div> {</div><div> "id":"1-1",</div><div> "name":"name1",</div><div> "state":"active",</div><div> "severity":1</div><div> },</div><div> [</div><div> "1-2",</div><div> "name2",</div><div> "active",</div><div> 2</div><div> ]</div><div> ]</div><div>}</div><div>Note that a row can be either a {} or []</div><div><br></div><div><br></div><div>3. perform differential update:</div><div><br></div><div>PUT '/v1/data-sources/vitrage/tables/alarms' with body:</div><div>{</div><div> "addrows":[</div><div> {</div><div> "id":"1-1",</div><div> "name":"name1",</div><div> "state":"active",</div><div> "severity":1</div><div> },</div><div> [</div><div> "1-2",</div><div> "name2",</div><div> "active",</div><div> 2</div><div> ]</div><div> ]</div><div>}</div><div><br></div><div>OR</div><div><br></div><div>{</div><div> "deleterows":[</div><div> {</div><div> "id":"1-1",</div><div> "name":"name1",</div><div> "state":"active",</div><div> "severity":1</div><div> },</div><div> [</div><div> "1-2",</div><div> "name2",</div><div> "active",</div><div> 2</div><div> ]</div><div> ]</div><div>}</div><div><br></div><div>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.</div><div><br></div><div>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.</div></div>
</blockquote></div></div></div></div>