RT::Extension::REST2 - Get full ticket history

Hi!

I’m a software developer at a Dutch ISP, XS4ALL Internet. We’ve been using RT for several years now. Recently we’ve started integrating RT into our new CRM. For that we are using the REST 2.0 plugin we’ve found on your MetaCPAN (https://metacpan.org/pod/RT::Extension::REST2).

Now I’m running into an issue with getting all the contents for a single ticket. As it currently seems, I need to GET /ticket/{id}/history and then iterate over each transaction, and its attachment.
For an average ticket this would easily result in between 20 to 60 GET-requests… That can’t be right.

In the REST 1.0 documentation I’ve read that I can use ?history=l to prevent this iterating.
You even write “…but that is extremely wasteful and will scale horribly.” :wink:
https://rt-wiki.bestpractical.com/wiki/REST#Ticket_History

Is there a way I can do something similar for the REST 2.0 interface?

Thank you so much in advance.

Twan

Hi Twan,

There are things that are easier to do in the REST 1.0 interface. I would use it when you need to. REST is REST. You could submit a patch to implement this in REST 2.0. But that would be much more work than just using the 1.0 when needed.

Regards,
Ken

Hey Twan,

We run into the same issue you discovered. I’ve extended the REST 2.0 API to allow specifying additional fields to fetch, which can also expand some of the blocks (like Creator etc) to include the fields you need to reduce the round trips. The version on CPAN includes the first changes for this, the others which extend the usefulness are in our github (and there are pull requests…). Have a look at:

Cheers,
Andrew

Hey Andrew!

Thanks! But this currently doesn’t yet support getting the full history with one request right? At least, I wasn’t able to get that from the README. And if it does, would you care to explain? (I’m fairly new to all this REST stuff, I come from RPC-country…)

For now we decided to use the REST2 interface to just show the existence of a ticket (with a few details) in our CRM and then leave the viewing and editing up to RT’s front-end. Perhaps in future iterations we’ll just use the good 'ol REST1 interface for fetchting the history.

Twan