[dev.icinga.com #305] Make all objects accessible by URL

[icinga-migration]

This issue has been migrated from Redmine: https://dev.icinga.com/issues/305

Created by jhein on 2010-02-24 22:04:32 +00:00

Assignee: jmosshammer
Status: Resolved (closed on 2010-05-19 13:46:44 +00:00)
Target Version: (none)
Last Update: 2010-05-19 13:46:44 +00:00 (in Redmine)

---

This is an issue that came up from someone through twitter. They need to remote control their web frontend. In Nagios it is possible to select almost anything by an external URL. You can directly access als the services from a given host or make special selections like all "all problems not in a downtime".

It would be great if we had the same possibility for the new web interface.

Changesets

2010-05-19 13:09:15 +00:00 by jmosshammer f62674c

* Added URL-driven Icinga-API requests (resolves #305)
* API Requests can now be done via GET or POST requests

[icinga-migration]

Updated by mfriedrich on 2010-02-25 16:27:45 +00:00

we had a discussion about that today too. It's a minor wish but will be much appreciated when stepping over to Icinga and the new web.

the thing is, persistent views by user are nice, but handing over an url (e.g. from a notification email or similar documentation stuff) makes life easier.

[icinga-migration]

Updated by jhein on 2010-02-25 17:08:27 +00:00

• Subject changed from Make all objects available by URL to Make all objects accessible by URL

[icinga-migration]

Updated by jmosshammer on 2010-05-17 10:56:28 +00:00

• Status changed from New to Assigned
• Assigned to set to jmosshammer

Allow access to icinga hosts/services via Html urls.
E.g. icinga-web/icinga-api/hosts/name[]/json|xml

[icinga-migration]

Updated by jmosshammer on 2010-05-19 13:46:44 +00:00

• Status changed from Assigned to Resolved
• Done % changed from 0 to 100

API Searches can now be performed via URL. The principals for the current user affect the result.
The syntax should be like this (assuming its on localhost).

Fields in () are optional.

The base request must be:
http://localhost/icinga-web/web/api/%ICINGA\_TARGET%/

Then, in arbitary order the search can be fine adjusted with the following field, delimited by /:

-filter[AND(COLUMN_1|RELATION_1|FILTERVALUE_1;$COLUMN_2|$RELATION_2|$FILTERVALUE_2;...;$COLUMN_n|$RELATION_n|$FILTERVALUE_n])

Filters the result by column COLUMN with relation RELATION (=,!=,<,>,>=,<=,like) and value FILTERVALUE

-groupGROUP_COLUMN

Groups the result by column GROUP_COLUMN

-columnsCOLUMN_LIST

Shows only the columns given by COLUMN_LIST, which is a csv delimited by '|'

-order[ORDER_COLUMN;DIRECTION]

Returns the result ordered by ORDER_COLUMN in direction DIRECTION (can be 'asc' or 'desc')

-limit[(START_OFFSET;)LIMIT]

Returns only LIMIT results, optionally starting at offset START_OFFSET to support paging.

At the end the url must contain xml or json, in order to set the output format.

Example: Requesting the first 10 entries of host_status_history that have state 1 in descending id order. Format the result as xml:

http://localhost/icinga-web/web/api/host_status_history/filter[STATEHISTORY_STATE|=|1]/order[STATEHISTORY_ID;desc]/limit[0;10]/xml

POST Requests:
All parameters except the output type and the target can be added via POST. This has the advantage that more than one filter can be applied. Of course, this can be combined.

If the following POST parameters will be send to the url above, only entries with state_history_object_id 1234 and lower will be displayed, additionally to the state 1 condition:

filters[0][column]=STATEHISTORY_OBJECT_ID & 
filters[0][relation]= <=
filters[0][value] = 1234