Extending the API

Quick overview of how Opsview's API works:

Request gets into Catalyst. Is evaluated at opsview-web/lib/Opsview/Web/Controller/Api.pm. This has a begin and end of Deserialize and Serialize respectively. This means that any XML is expanded out before subroutines here are processed. This expansion happens in opsview-core/lib/Opsview/XML.pm (is in opsview-core because XML maybe used by core code in future).

After expansion has happened, Catalyst will call the do_api routine. Here, you do general stuff (like authentication), and then you work out what the request actually wants to do. For configuration changes, the idea is that the object is found and then the action takes place via the class Opsview::CRUD::{objecttype}. This class is a very thin wrapper to Opsview::{objecttype}, but will be expanded over time - one idea is to do more database transactions at this class level (there seems to be discussions about this on the Catalyst mailing lists about using an adaptor class - maybe this is where this is at?).

Not all objecttypes are supported yet, but should be easy to grow.

If you make any changes around the XML or the API, make sure opsview-core/t/601-xml.t and opsview-web/t/{600-api.t,610-cmdline.t} are updated. The latter two require a catalyst server to be running before you can run the tests, so is not well automated yet.

The schema for the input data is on http:{youropsviewserver}/xml/opsview.rng (in RELAX NG format) which is /usr/local/nagios/share/xml/opsview.rng (within opsview-core/share/xml on dev servers)