Thanks K-T, few answers:
Confluence page or an in-repo RST/MD file would be better to store design docs.
I'll transfer this to Confluence (or Trac), I'm not sure that general design docs should appear in repo.
I tend to dislike Unix sockets as well.
HTTP/TCP for now and HTTPS later?
OK. Still I'd like to keep ssh option. There may be other issues beyond our control (firewalls) that can prevent direct TCP access.
You could use PUT /dbs/<db> etc. instead of POST /dbs etc. since the client knows the resulting URL already.
I thought about that and I did not like it. I think usually when you want to create database you want to have it empty (no tables). PUT has to be idempotent which probably maps better to "create if database does not exist, drop all tables if it exists". I think I prefer explicit DELETE to drop database with tables and POST which means "create if does not exist, fail if exist" and is not idempotent.
Is PUT /dbs/<db>/tables/<table>/data expected to take all the data for the entire table, or is this incremental
It should be incremental. I thought that existing data would be overwritten if you want to load identical data. But sure one can argue that it should be an error to attempt to overwrite existing data. Should we support both (PUT for overwrite and POST for "append-only")? I'm also OK with just disabling overwrite and switching to POST.
PUT /services/<service> should be setting a state, not performing an action, and it should be idempotent. Perhaps PUT /services/<service>/running instead?
Well, the same state can be reached in different ways. Suppose I want running state, but the service is already running, should it just say "OK" or restart service? Sometimes I want to do explicit restart as opposed to just making sure that service is running. For restart I could probably do it in two steps going to stopped and then to running again, but this logically may be different from single restart action. I do not know good RESTful way to solve this problem, we can probably introduce restarted state to solve it but this looks very ugly.
Logging should be handled separately.
OK, I won't mention it again.