API work

[roger peppe]

On 6 November 2013 13:30, William Reade <william.reade at canonical.com> wrote:
> On Wed, Nov 6, 2013 at 1:49 PM, roger peppe <rogpeppe at gmail.com> wrote:
>>
>> FWIW I'm strongly in favour of *not* sending charms through
>> the RPC interface - it is likely not incur a significant performance
>> hit over a high latency connection. I don't *think* that implementing
>> a PUT handler on the API server should be too much of a problem.
>
>
> I'd like to see a slightly more detailed plan here, but I'm not against that
> in principle.

So, we discussed some of this in SFO. The only wrinkle is that
currently the websocket-based is available on every path of
the exported HTTP interface (that is, connecting to
wss://my.juju.server/lkdjnsvfdv
will give you the API just as well as wss://my.juju.server/.

Long term, I'd like to deprecate the root as a way of talking to the API
and mandate (for instance) /api as a URL path. Short term, we
can't do that, but we *can* treat, for instance /charm differently
and serve PUT (and potentially GET requests) on that.
It's just a matter of adding a ServeMux  in apiserver.Server.run.

The other issue we'd need to deal with is authentication. I'd suggest
we would specify that the URL parameters should include the
user name and password. If we didn't want to do that, there are
alternatives which I won't go into here as they're more complex.

So to summarise, the URL might look something like:

https://my.api.server/charm?user=admin&password=adminpassword&charmurl=cs:precise/wordpress

We'd do a PUT request on the above URL, sending the charm
bundle. We may well want to add a secure hash of the charm bundle too,
so that we can tell if the user accidentally drops the connection too
early.

I don't think that charms are generally big enough to warrant adding resumable
uploads, at this point anyway.

How does that sound?