I agree that there is room for improvement, as I had to find out by
inventory via the Ruby Gem.
What timeline do you have in mind, the changes seem large and will
probably impact not only inventory, but also the RubyGem (and existing
code in MiQ), the WF agent, the work of our GSoC students and others,
that we may not even know of.
Would it make sense to keep the old api in parallel for a while and
request the new one via different media type or api-root?
Here I propose a reformed REST API centered around the canonical
I like that - especially for things like GET requests where the CP is
and all cases of "create something below X", where X can be identified
I think we already return the CP in all objects, so re-using this in
This is useful for scenarios like "querying all EAPs". The
is that you'd have your resource type that you expect defined and a
level, possibly contained in a metadata pack. You'd then look for
Which we need for such types as EAP.
==== Access Entity By Canonical Path
Will the '/' in the CP need encoding. If so, I propose to change this
to a character that does not need url-encoding.
Otherwise requests get non-human-readable
Which may get worse for local parts that contain '/' again as in the
I think it would help me to explicitly write some of those
cases down (full working curl-command).
==== Accessing Targets of Relationships
I can't say I particularly like it - probably because it is longer
This is equivalent to the current
(notice the trailing slash)
This sounds like a constant source of confusion
"give me all children of resource with id
==== Accessing Relationships
(notice the lack of trailing slash)
together with this.
"find all the 'contains' relationships going out of the
feed with id
result set (to be able to sort or determine the total). We may think
some kind of server-side "live result set" that would hold the results
server and be accessed using some kind of token (with a TTL). This is
neo4j does it and would avoid having to fetch the full result set on
Sounds good. Do we know though how much paging is currently used?
Right now in the MiQ use case we don't use it, but that may change in
the future when we have to pull in hundreds or thousands of servers
== POST URLs
URI = "/", CP, "/", "resource" | "metric" |
"resourceType" | ...;
SO with a CP starting with '/'
is this then POST /%2f;bla%2f;tfoo/resource ?
The idea here is that you can create the entities only at their
What is the CP of something that does not exist yet? Or does the above
represent the to-be parent ? Looks like the latter from the examples
positions. While the Java API allows for creation after a
traversal, I think this would be unnecessarily complicated for the
The users would pass the familiar blueprint objects to these endpoints
/feed - send a feed blueprint and this will create a new feed
/resourceType - send a resource type blueprint and it will create a
/f;feed/resourceType - creates a feed-local resource type
== PUT URLs
URI = "/", CP
just send an update object corresponding to the type of entity on the
== DELETE URLs
URI = "/", CP