Cheers Craig, that's about what I was assuming was the case to be honest. The
hardest thing I've found to try and get out of REST was 'node availability over
last X days' - the db function that calculates this looks at
sum(outages)/count(managed services), the latter of which isn't something you
can fetch in bulk over REST as it's in the form rest/nodes/<node
criteria>/ipinterfaces/. I *could* expose a list of all ip interfaces through
REST, though I'm not sure if that's creeping too far. Your thoughts?
That aside, I needed to make two minor tweaks to the current REST api: making
nodeparentid visible on nodes (changing it from @XmlTransient to @XMLIDRef) and
adding a page to fetch a list of all known categories. Both seem generic enough
to upstream, so I've put them in enhancement ticket NMS-4893.
Thanks,
Duncan
________________________________________
From: Craig Miskell [cr...@stroppykitten.com]
Sent: 22 August 2011 21:12
To: OpenNMS Code Development and Bugs
Subject: Re: [opennms-devel] Getting node lists with status out of REST
On 23/08/11 4:32 AM, Duncan Mackintosh wrote:
> I'm working on improving our internal geolocation node map (based on the
> work Alex Bennee started) and trying to migrate it to use Hibernate
> instead of direct SQL, starting with the REST api.
>
> Presently it doesn't seem at all easy to get "all nodes, and for each
> node a list of alarms and recent outages" out of the rest pages without
> doing separate queries and joining the data up on the client side. I'd
> rather avoid this.
>
> Is what I'm trying to do outside the scope of rest, or would it be
> profitable to extend the rest package to permit fetching of "NodeState"
> elements which contain information from various sources bundled together?
>
> Obviously as this is internal we can make it work just by keeping the
> direct SQL queries, or move the servlets to use Hibernate, but we'd much
> rather share any useful rest changes upstream and keep the forking
> minimal. So: what is the intended scope of the rest api?
Hi Duncan,
Speaking only from my own vantage point, I think that the ReST API
should remain as simple as possible for any given entity. One call to
get node(s), one to get outage(s) one to get alarm(s) etc. There is scope
for the calls to "get outages" or "get alarms" to have a filter with
multiple node ids (without checking the docs, I seem to recall that's
already possible). That would keep it down to something like 3 calls in
your case, which doesn't seem excessive to me.
My concern is that otherwise we end up with a bunch of extremely
specific ReST APIs that are written with one particular UI in mind, and
that have to be maintained in perpetuity (not that maintenance is
overly difficult but it's got to be done). The other concern is that
something like NodeState is fairly broad, and could be justifiably
extended piece by piece until it ends up sucking down half the database
for a given node (ok, I exaggerate, but I hope you see my point).
All that said, there may be a case for such combined information in some
limited circumstances, where the individual queries would be more
complicated, or where the performance of doing it entity by entity would
be seriously degraded compared to a single carefully constructed join
and API query. But I would suggest it's the last resort, not the first.
--
Craig Miskell
==
">> consider moving away from Front Page...."
">To what? Any suggestions?"
"Naked bungee-jumping. It's less humiliating <g>"
-- Matt Probert in alt.www.webmaster, March 20, 2005
------------------------------------------------------------------------------
uberSVN's rich system and user administration capabilities and model
configuration take the hassle out of deploying and managing Subversion and
the tools developers use with it. Learn more about uberSVN and get a free
download at: http://p.sf.net/sfu/wandisco-dev2dev
_______________________________________________
Please read the OpenNMS Mailing List FAQ:
http://www.opennms.org/index.php/Mailing_List_FAQ
opennms-devel mailing list
To *unsubscribe* or change your subscription options, see the bottom of this
page:
https://lists.sourceforge.net/lists/listinfo/opennms-devel
Cambridge Broadband Networks Limited Registered in England and Wales under
company number: 03879840 Registered office: Selwyn House, Cambridge Business
Park, Cowley Road, Cambridge CB4 0WZ, UK. VAT number: GB 741 0186 64
------------------------------------------------------------------------------
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management
Up to 160% more powerful than alternatives and 25% more efficient.
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
_______________________________________________
Please read the OpenNMS Mailing List FAQ:
http://www.opennms.org/index.php/Mailing_List_FAQ
opennms-devel mailing list
To *unsubscribe* or change your subscription options, see the bottom of this
page:
https://lists.sourceforge.net/lists/listinfo/opennms-devel
