<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jul 29, 2014 at 6:57 PM, roger peppe <span dir="ltr"><<a href="mailto:rogpeppe@gmail.com" target="_blank">rogpeppe@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 29 July 2014 16:50, Eric Snow <<a href="mailto:eric.snow@canonical.com">eric.snow@canonical.com</a>> wrote:<br>

> The API server side of backup made it into 1.20 (the client-side and<br>
> CLI did not).  However, the API is exposed via HTTP POST rather than<br>
> through websockets RPC.<br>
<br>
</div>An HTTP POST request seems about right for a call that<br>
streams a significant amount of data. Is there any particular<br>
reason this has to change?<br></blockquote><div><br></div><div>It's not what we discussed and agreed in vegas; and, crucially, it fails to make previously-made backups available from any state server. We want WS APIs for creating, listing, and deleting backups; and, yes, we want to *download* those backups over HTTP, and the CLI will be creating them, waiting for them to be ready, and then downloading them over HTTP. But a POST to just create-a-backup-and-download-it-and-forget-about-it is not what we want or need.</div>
<div><br></div><div>WRT the proposal:</div><div><br></div><div>Given that we explicitly flagged the POST API as experimental, and we didn't release a client that actually used it, I think we're safe fixing and backporting (although, remember, the 1.18-based backup/restore needs to continue to work -- this lets us handle only *two* mechanisms rather than three, it doesn't let us use just one).</div>
<div><br></div><div>But I'm a bit suspicious... would someone please confirm that we don't have *any* released clients that use the POST API? The above is predicated on that assumption.</div><div><br></div><div>Cheers</div>
<div>William</div></div></div></div>