[Rt-devel] RT API

[Bob Goldstein]

>There is an RT API called REST:
>/opt/rt3/share/html/REST


   I posted this exact question (phrased slightly differently)
   a couple weeks ago.  In my case, REST (used by the cli 'rt')
   wasn't comprehensive enough to deal with groups.

   Do note that the rt (command line program) uses the
   REST interface, and does not have to run on the RT machine.

   Todd Chapman pointed out RT::Atom.  That looks promising
   for my needs, although I haven't had time to fully investigate.

   I was kinda asking about a SOAP-like interface, to deal with
   more complex data structures, and Jesse replied that he
   prefers the simplicity of the name-value (rfc822-style) forms
   used by the current REST interface.

   Anyway, looking over your list of needs, only the last
   one (interaction with PDAs) would need such an interface.
   The key point there is real-time, low-latency.  The rest of
   your items can tolerate some latency, and so the usual
   tools (e.g. the RT perl API) can be used.  A few comments below.

      bobg

>> Have the development team ever considered the benefits of introducing 
>> an RT API ?  I'd like to see a HTTP-POST / XML reply interface into 
>> the RT system.  This will allow us to :
>>
>>
>>  - update tickets in an automated way (letting some tickets expire)


     rt-crontool does this.  And you can certainly write what you
     like with the perl API and use cron.

>>
>>  - create tickets when a given event is triggered (i.e. association 
>> between Nagios and RT for some alerts)

     An example of nagios using the rt command line for this:

     http://lists.bestpractical.com/pipermail/rt-users/2005-June/031775.html


>>
>>  - build custom reports for IT management.


     The few times I got into this, I ended up doing my
     own selects.  A web api would not, by itself,
     make this any easier.

>>
>>  - allow us to extend the features of our email interface (e.g. permit 
>> managers to send control messages to an interface which lets them mark 
>> jobs against particular users.)

     I did something very similar.  I modified the RT mail processing
     (based on earlier suggestions by Jesse) to look for certain formats
     and execute commands.  In my case, I needed to populate a custom
     field when certain email came it, and to route it to a queue
     based on field in the email.  It would be trivial to have it
     assign to a particular user, or whatever you needed.  Then I put
     a pipe stage in front of rt-mailgate, to munge what we had
     into what RT would digest.



>>
>>  - allows developers to integrate RT with handheld devices (which we 
>> really could do with).

     Here you are asking for an alternate realtime UI.
     The REST interface might well suit you, whether you use it directly
     via http posts, or indirectly by calling the rt command line.
     You can already create, fetch and update tickets.



>>
>>
>> Any thoughts ?
>> -a
>> _______________________________________________
>> List info: 
>> http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-devel
>>
>> Best Practical is hiring! Come hack Perl for us: 
>> http://bestpractical.com/about/jobs.html
>>
>
>_______________________________________________
>List info: http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-devel
>
>Best Practical is hiring! Come hack Perl for us: http://bestpractical.com/abou
>t/jobs.html
>