Hi,
I created a form on our homepage that can create tickets using the REST
Interface. With the form the user is able to add further information to
his tickets, or mark them as resolved.
But every time the user adds information via the form, the creator is
wrong. The creator is always the user that is authenticated - which is
basically correct. But as the customer-login has no access to the REST
API (gets always redirected to /SelfService), I cant use his login to
create the history entry.
How can I create a correspondence/comment that has the same creator as
the tickets requestor with the REST Interface?
Hello, RT developers !
At the German Perl Workshop in Erlangen next month I’ll talking about automating and integrating RT
through the REST interface (http://www.perl-workshop.de/talks/102/view).
rt help list says:
(Right now, the server doesn’t support listing anything but tickets.
Other types will be supported in future; this client will be able to
take advantage of that support without any changes.)
Are there any plans to add this support ? If not would you accept patches ?
Besides that, the interface violates main principles of RESTfulness, like
uniquely addressable and well defined operations. Just to let you know that
I’ll cover these weaknesses :-).
Regards
Racke
LinuXia Systems => http://www.linuxia.de/
Expert Interchange Consulting and System Administration
ICDEVGROUP => http://www.icdevgroup.org/
Interchange Development Team
Hello, RT developers !
At the German Perl Workshop in Erlangen next month I’ll talking about
automating and integrating RT through the REST interface
(http://www.perl-workshop.de/talks/102/view).
Excellent. Are you aware of dams’ RT Console client and the cpan library
for working with the REST interface?
http://code.google.com/p/rt-client-console/
rt help list says:
(Right now, the server doesn’t support listing anything but tickets.
Other types will be supported in future; this client will be able to
take advantage of that support without any changes.)
Are there any plans to add this support ?
It’s not high on the list. We’re hard at work on RT 3.8 which doesn’t
touch REST much and RT4, which leaves the existing RESTy interface in
place but also exposes EVERY object via a proper REST interface (with
json, xml, perl, yaml data transports and proper URLS)
If not would you accept patches ?
YES! 
Besides that, the interface violates main principles of RESTfulness, like
uniquely addressable and well defined operations. Just to let you know that
I’ll cover these weaknesses :-).
In my defense, when the REST interface got designed, everyone else on
the planet was just starting to use SOAP and Roy Fielding had barely
published his definitions of what REST was. It wasn’t well understood by
anybody. What I’d taken away from the discussion about what REST could
be at the time was “access via simple GET and POST at simple, defined
end points.” Were I doing it over today (as I am ;), I’d do it
differently.
Best,
Jesse
Jesse Vincent wrote:
Hello, RT developers !
At the German Perl Workshop in Erlangen next month I’ll talking about
automating and integrating RT through the REST interface
(http://www.perl-workshop.de/talks/102/view).
Excellent. Are you aware of dams’ RT Console client and the cpan library
for working with the REST interface?
Google Code Archive - Long-term storage for Google Code Project Hosting.
I looked at the CPAN library, but decided to roll my own code as the
complexity of the REST interface is moderate and integrating the
said module into Interchange (which is the whole purpose) needs
extra code anyway. But thanks for the hint, I’ll factor them into
the paper / reference list.
rt help list says:
(Right now, the server doesn’t support listing anything but tickets.
Other types will be supported in future; this client will be able to
take advantage of that support without any changes.)
Are there any plans to add this support ?
It’s not high on the list. We’re hard at work on RT 3.8 which doesn’t
touch REST much and RT4, which leaves the existing RESTy interface in
place but also exposes EVERY object via a proper REST interface (with
json, xml, perl, yaml data transports and proper URLS)
Great.
If not would you accept patches ?
YES!
Besides that, the interface violates main principles of RESTfulness, like
uniquely addressable and well defined operations. Just to let you know that
I’ll cover these weaknesses :-).
In my defense, when the REST interface got designed, everyone else on
the planet was just starting to use SOAP and Roy Fielding had barely
published his definitions of what REST was. It wasn’t well understood by
anybody. What I’d taken away from the discussion about what REST could
be at the time was “access via simple GET and POST at simple, defined
end points.” Were I doing it over today (as I am ;), I’d do it
differently.
I read that the REST stuff was introduced with RT3 and was ignorant of the
fact that it is ancient code.
Oh, and thanks for the terrific software. I just started about 9 months ago
for me and my customers and the feedback is really positive. Now to some
code that exports the time information from the various RT instances into
my billing …
Regards
Racke
LinuXia Systems => http://www.linuxia.de/
Expert Interchange Consulting and System Administration
ICDEVGROUP => http://www.icdevgroup.org/
Interchange Development Team
In my defense, when the REST interface got designed, everyone else on
the planet was just starting to use SOAP and Roy Fielding had barely
published his definitions of what REST was. It wasn’t well understood by
anybody. What I’d taken away from the discussion about what REST could
be at the time was “access via simple GET and POST at simple, defined
end points.” Were I doing it over today (as I am ;), I’d do it
differently.
I read that the REST stuff was introduced with RT3 and was ignorant of the
fact that it is ancient code.
Well, that’s still 2001-2002 or so. 7 years isn’t forever, but it’s a
LONG time ago 
Oh, and thanks for the terrific software. I just started about 9 months ago
for me and my customers and the feedback is really positive. Now to some
code that exports the time information from the various RT instances into
my billing …
That’s very cool. I’m sure there are other folks who’d love to see the
interchange integration
Best,
Jesse
Jesse Vincent wrote:
[…]
(Right now, the server doesn’t support listing anything but tickets.
Other types will be supported in future; this client will be able to
take advantage of that support without any changes.)
Are there any plans to add this support ?
It’s not high on the list. We’re hard at work on RT 3.8 which doesn’t
touch REST much and RT4, which leaves the existing RESTy interface in
place but also exposes EVERY object via a proper REST interface (with
json, xml, perl, yaml data transports and proper URLS)
That sounds promising :-). Do you just give a preview on your RT 4 plans or
is there actual code for it ?
If not would you accept patches ?
YES!
Besides that, the interface violates main principles of RESTfulness, like
uniquely addressable and well defined operations. Just to let you know that
I’ll cover these weaknesses :-).
In my defense, when the REST interface got designed, everyone else on
the planet was just starting to use SOAP and Roy Fielding had barely
published his definitions of what REST was. It wasn’t well understood by
anybody. What I’d taken away from the discussion about what REST could
be at the time was “access via simple GET and POST at simple, defined
end points.” Were I doing it over today (as I am ;), I’d do it
differently.
Well, I found that you actually can do /REST/1.0/user/racke/show. I didn’t notice
that because /usr/bin/rt fails to request RESTfully :-).
Regards
Racke
LinuXia Systems => http://www.linuxia.de/
Expert Interchange Consulting and System Administration
ICDEVGROUP => http://www.icdevgroup.org/
Interchange Development Team