[Bug 2213] [STORY] Rework Web API

[bugzilla-daemon at icedtea.classpath.org]

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=2213

Mario Torre <neugens.limasoftware at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |neugens.limasoftware at gmail.
                   |                            |com

--- Comment #3 from Mario Torre <neugens.limasoftware at gmail.com> ---
(In reply to Severin Gehwolf from comment #2)

> > The vmID/agentID/hostname in the URL is unnecessary as the collections
> > aren't separated this way and the entries contain this data. The downside is
> > it is more difficult to have authorization based on this data.
> 
> We need to have a hierarchical view of things. Precisely for the reasons of
> security. That is the path-info should include bits to whatever the metric
> is associated with. Numa metrics for a host might be
> /storage/<hostname>/numa. Numa metrics for a vm might be /storage/<vm>/numa

Indeed, and we should consider this is an abstraction, so even if the
collections are not separated this way in the underlying system we should keep
this level of separation.

So to query threads states on vm #1 on agent #0 we would craft a base path such
as:

agent0/vm1/threads/vm-thread-state

As Severin notes we need to carefully understand how the specifics of this
query works, so for example if we want to pass sort/ordering and filtering
information as part of the path or as parameter, or if we extend the paths:


agent0/vm1/threads/vm-thread-state/limit/5

vs

agent0/vm1/threads/vm-thread-state?limit=5

etc..

I suspect the former will be easier to parse and more coherent, particularly if
we consider command channel requests and the fact that paths are easier to
craft for external clients, it may also make it easier to add selective
permissions on queries and statements, on the other end, this may turn up to be
too inflexible since complex queries are not really possible. Of course this is
just an idea and we should carefully think about that, there may be different
solutions too.

What I find cool about this approach is that we can enable more filtering and
sorting on the server side and not bother to create multiple distinct hardcoded
queries in the code. Since access to data is "filesystem-like" we don't care
anymore about having a predefined set of compile time based queries and
statements that are permitted, we just consider documents and categories as
files and directories, and the command channel as execution bits. Also user
permissions and login can be delegated to external methods like kerberos and
such, that would make administration much easier, so they don't need to be part
of this API specifically and is a separate problem, other than the "how we pass
credentials" bit.

Btw, this is a great opportunity to clear up the agent vs host distinction, and
also an opportunity to assing an unique id to hosts that never changes (not
directly related to this bug, but kind of related).

> > Integration alongside the current Web API also needs consideration. Current
> > users access data through DAO objects where the actual implementations of
> > data acquisition are hidden. This system should probably be maintained such
> > that the use of the new or old Web API can happen underneath, without
> > changing the calls users make of the DAO objects. New access methods can be
> > provided as well.
> 
> DAO abstractions should not go away. However, we might consider simplifying
> that. Suggestion would be to re-design that part after we've nailed down v1
> of the new, stateless, Web API.

I agree, we may decide that since all our communications happens across the web
layer anyway the current DAO could become an implementation detail and be
phased out from general use, but this is something in the longer term to
consider, and only when we see that the REST API has benefits.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20161111/85eabc66/attachment-0001.html>