Jesse (or anyone else!), I have some general comments on RT’s
REST interface. I’ll probably write something to suit my
immediate needs, but if you think this might be interesting, I’d
rather organize it to help others as well.
My immediate need is that I want to query and control user
parameters from a separate program, one that we use for general
account provisioning. Basically, RT is too important to be
standalone; I want to be able to create and deactivate users, and
change their privs (group memberships) from a central place.
I could imagine other uses. Maybe, with Asset Tracker,
there’s a reason some asset wanted to update RT in some way.
Or maybe with multiple RT instances, we could achieve some
limited linkages with one instance making changes to a related
ticket in another instance. Or in general, as RT expands,
rather than make it into a one-program-does-all, you make it
interact with different but related programs like asset trackers,
CRM, bug trackers, project management, change management, or
other helpdesk systems that management won’t let us jettison.
Seems to me, there are two ways an external program can
interact with RT – email and web. Email has authentication
issues, and the asynchronicity makes it hard to confirm
success/error of the requests. REST, however, would be perfect.
Now, the current REST interface doesn’t do groups, my first
concern. But I’ve come to realize, it is organized for ‘rt’, the
command line processor. Specifically, it transmitts in “forms”,
basically ascii name-value pairs, as opposed to, say,
Data::Dumper representation of more complicated perl structures.
And secondly, to add/delete something, there is too much
intelligence required in the client. ‘rt’ has to query the
status, figure out how to change the status to reflect the
required addition or deletion, and then resubmit the new status.
As opposed to telling the server, “Hey, add this”, and get back
either “done”, “moot” or “error”.
The end result is that an external program would probably munge
the data into a system call to rt, and then munge the result back
into a perl structure. As opposed to just including a library,
and making the lwp call directly. Somehow it ought to
Is any of this worth pursuing?