I am working on some code in ruby that accesses the REST interface. I am
running RT 3.8.2. I am able to login, save cookies, and retrieve tickets
and history without problems.
My problem starts when I try to use REST to add a comment/correspondence to
a ticket. The following code:
url = “#{REST}ticket/846/comment”
req = Net::HTTP::Post.new(url)
req.add_field ‘User-Agent’,UA
req.add_field ‘Cookie’,cookie
req.set_form_data( { “Action” => “comment”,
“Text” => “This is some text” } )
response,data = http.request(req)
puts response.code + " " + response.message
puts "Data: "
puts data
produces this output:
200 OK
Data:
no value sent for required parameter ‘changes’
Stack:
[/opt/rt38/share/html/REST/1.0/dhandler:285]
[/opt/rt38/share/html/REST/1.0/autohandler:54]
[/opt/rt38/share/html/autohandler:311]
I’ve looked at /opt/rt38/share/html/REST/1.0/dhandler line 285 and there is
a method call $m->comp with no mention of a parameter named ‘changes’, which
is quite possibly the problem. Later in the file there is another $m->comp
call that has a ‘changes’ parameter.
I suspect this is a bug in share/html/REST/1.0/dhandler. But what I don’t
understand is why the RT command line tool can do it and I can’t. Anyone
else run into this?
– ============================
Tom Lahti
BIT Statement LLC
(425)251-0833 x 117
http://www.bitstatement.net/
– ============================
Tom Lahti wrote:
I am working on some code in ruby that accesses the REST interface.
I’ve re-written the whole thing using the rest_client ruby gem, and
essentially the same results, but I get more info out of what’s going on:
./resttest2.rb
--------------------- Request headers
{“User-Agent”=>“Mozilla/5.0 fake 0.1”,
“Content-Type”=>“application/x-www-form-urlencoded”,
:content_type=>“application/x-www-form-urlencoded”,
“Cookie”=>“RT_SID_xxxx.net.443=[a_hex_session_id]”}
--------------------- Request payload
“Ticket=846&Text=This%20is%20yet%20another%20test.”
--------------------- Response headers
{:server=>
“Apache/[snip] mod_perl/2.0.3 Perl/v5.8.8”,
:date=>“Mon, 16 Feb 2009 23:24:29 GMT”,
:transfer_encoding=>“chunked”,
:content_type=>“text/plain; charset=utf-8”}
--------------------- Response Payload
no value sent for required parameter ‘changes’
Stack:
[/opt/rt38/share/html/REST/1.0/dhandler:285]
[/opt/rt38/share/html/REST/1.0/autohandler:54]
[/opt/rt38/share/html/autohandler:311]
Is it permissible to POST to the REST interface using content type
application/x-www-form-urlencoded? It would seem that the RT CLI does
something else but its difficult for me to figure out what.
Should I be asking about this on rt-devel instead?
– ============================
Tom Lahti
BIT Statement LLC
(425)251-0833 x 117
http://www.bitstatement.net/
– ============================
no value sent for required parameter ‘changes’
Stack:
[/opt/rt38/share/html/REST/1.0/dhandler:285]
[/opt/rt38/share/html/REST/1.0/autohandler:54]
[/opt/rt38/share/html/autohandler:311]
I seem to have figured this out. You can use
application/x-www-form-urlencoded, but you have to create a single form
field named “content”, and it must contain the entire form in RFC822 format.
I didn’t really see that documented anywhere I was looking, so perhaps the
documentation is somewhat lacking.
For example, where I had this:
req.set_form_data( { “Action” => “comment”,
“Text” => “This is some text” } )
I changed to this:
req.set_form_data( { “content” => “Action: comment\nText: This is some text” })
and it works as desired.
For the “Text” parameter in the content, if you want to add a multi-line
comment it seems you have to have white-space at the beginning of
continuation lines, otherwise the RT “form parser” in the REST interface
thinks its a syntax error; any line with a character in the first column is
expected to be a field name within the form.
It also seems bizarre to me to implement the interface that way. Basically
its like making a web page with a single text area named “content” and then
requiring formatting within that one field. Why not have the REST interface
have discrete fields? Coding to it would be certainly be cleaner. Maybe
for /REST/2.0/ ? 
– ============================
Tom Lahti
BIT Statement LLC
(425)251-0833 x 117
http://www.bitstatement.net/
– ============================
It also seems bizarre to me to implement the interface that way. Basically
its like making a web page with a single text area named “content” and then
requiring formatting within that one field. Why not have the REST interface
have discrete fields? Coding to it would be certainly be cleaner. Maybe
for /REST/2.0/ ?
When it was implemented in 2002(?) or so, REST best practices were much
less clear. And the initial design goal involved being able to implement
a commandline client as a shell script with wget and a text editor.
RFC822-encoded forms were a very straight forward way to get from A to
B.
If I were doing it today[1], I’d do it differently.
-Jesse
[1] And indeed, RT4 is based on Jifty and serves up both the legacy /REST/1.0 interface and Jifty’s much more modern REST interface: http://cpansearch.perl.org/src/SARTAK/Jifty-0.80408/lib/Jifty/Plugin/REST/Dispatcher.pm