[Bug 2213] [STORY] Rework Web API

[bugzilla-daemon at icedtea.classpath.org]

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

--- Comment #2 from Severin Gehwolf <sgehwolf at redhat.com> ---
(In reply to Jie Kang from comment #1)
> In terms of url access paths and data format, another alternative is to map
> them directly to the collections.
> 
> /storage/{collection-name}
> GET /storage/vm-info :: gets all entries in vm-info

All queries without explicit selection should be limited by default. Clients
need to provide extra steps to get more records if there are more. Example:

GET /storage/vm-info?offset=XXX

That would get the next <batch-size> of elements starting at offset XXX.

> POST /storage/vm-info :: adds a new entry in vm-info
> 
> 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

It's also worth noting that we should have built in support for extensions.
Perhaps we should have another level of hierarchy for plugins:

GET /storage/<vm>/<vm-plugin>/foo
GET /storage/<host>/<host-plugin>/foo

Maybe the supported plugins shall be discoverable by:

GET /storage/describe/plugins/host
GET /storage/describe/plugins/vm

> More enhanced queries could also be supported server-side such as filtering
> 
> /storage/{collection-name}/{field}/{value}
> GET/storage/vm-info/vmId/avmid :: gets all entries where field 'vmId'
> matches 'avmid'
> 
> This probably needs thought as it's currently limited to filtering over a
> single field. The easiest way is to include such data within the request,
> which the server-side then parses, but I would much prefer not doing so.
> 
> The server-side support for enhanced query API should be carefully
> restricted for security and lower workload, as client's can manipulate data
> as well. At the same time, enhanced queries can dramatically reduce the
> amount of data being transferred.

Yes, we need a way to encode queries somehow. This needs careful design.
Research on how other APIs designed this would be useful.

In general, specific queries should be part of the query string like so:

GET /storage/<vm>/compiler?fooparam="bar"&other="[x,y,z]"

In the above example, param "other" get's a list of values "x", "y", "z".

Every singular query (one hostname/agent/vm/what-have-you) should have a plural
counterpart:

GET /storage/vms?items="[vm1,vm2,vm3]"

Gets all vm infos for VMs "vm1", "vm2", "vm3", etc.

> 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.

-- 
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/00d1ae5d/attachment.html>