Andrei Savu updated ZOOKEEPER-809:

    Attachment: SPEC.txt

I've attached the first draft of the SPECs for an improved REST gateway. 

I'm proposing the following new operations:

1. create a new session -- POST /sessions/v1?op=create HTTP/1.1

2. keep the session alive -- PUT /sessions/v1/<SESSION-ID> HTTP/1.1

3. close the session -- DELETE /sessions/v1/<SESSION-ID> HTTP/1.1

4. create an ephemeral node -- POST 
/znodes/v1/a/b?op=create&name=c&ephemeral=true&session=<SESSION-ID> HTTP/1.1

5. create a new watch -- POST /znodes/v1/a/b?op=watch&view=data OR 
children&session=<SESSION-ID> HTTP/1.1

6. query watch status -- GET /sessions/v1/<SESSION-ID>/watches/<WATCH-ID> 
This operation could support long-polling in the future. 

7. delete a triggered watch -- DELETE 
/sessions/v1/<SESSION-ID>/watches/<WATCH-ID> HTTP/1.1

Let me know what you think about this. Am I breaking the REST principles? 

This is what I want to do in the first iteration. In the second iteration I 
would like to add support for ACLs and authentication. 

> Improved REST Interface
> -----------------------
>                 Key: ZOOKEEPER-809
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-809
>             Project: Zookeeper
>          Issue Type: Improvement
>          Components: contrib
>            Reporter: Andrei Savu
>            Assignee: Andrei Savu
>         Attachments: SPEC.txt
> I would like to extend the existing REST Interface to also support:
> * configuration
> * ephemeral znodes
> * watches - PubSubHubbub 
> * ACLs 
> * basic authentication
> I want to do this because when building web applications that talks directly 
> to ZooKeeper a REST API it's a lot easier to use (there is no protocol 
> mismatch) than an API that uses persistent connections. I plan to use the 
> improved version to build a web-based administrative interface. 

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

Reply via email to