Hi Kim,
- Cross-posting is not quite nettiquetish for many a lister.
- You will need to specify versions of RT, OS, environment (Web
server, mode), etc. Generic questions will most surely give you
generic answers.
- By REST you mean just GET/POST or are you actually trying to also
use PUT/DELETE HTTP methods on resources provided by RT. Usually REST
refers to the concept of a resource having it’s state defined in the
representation itself and using HTTP methods as a unique API to
fiddles with those resources, but I think you are referring to it as
some sort of API a la RPC, for the sake of not getting too
philosophical here, I would suggest just use “HTTP request” instead of
“REST request”.
Other comments below:
Developers,
Is there a place in RT where I can add logging to see what exactly RT is
getting when it receives a REST request? Re a place where I can print to the
log the http reest being received.
You can do many things for debugging. First you will probably need to
override the RT class with a custom class in the pre-defined custom
class directory of your RT installation. This may vary radically
between different OSs, versions and deployment methods (OS package
versus manual install for example). Assuming you are using
Apache/mod_perl, the usually easiest approach is to just use print or
warn to the Apache logs and a have a dedicated tail -f
/var/log/foo.log (this last bit assuming some *nix flavor and depends
on your Apache logging configuration).
Other methods, and I have personally used it with RT sometimes, is
actually using the Perl debugger with mod_perl. Many people would
think this is hard, but it’s actually surprisingly easy!
As I have posted in another earlier message to this board, I continue to
struggle with why when I make a REST request for a new ticket from PHP CURL
code the ticket gets made, but the custom field in the content of the
request does not get set. When I make what I believe is the exact same
request via an html form the ticket gets made and the custom field gets set.
Again, just maybe the “REST” bit might not be exactly precise,
especially to some folks in the devel-list!
So apparetly the PHP CURL request is not exactly the same as the form
request but for the life of me I cannot figure out how they are different.
Logging I have added elsewhere in RT indicates that the CURL request is not
resulting in the custom field being set due to a permission issue. But why
the form doesn’t have this same issue I don’t know. Both methods are sending
the same user name and password as post args. And the custom field as a line
in the content. Both request are successful, but only the form method sets
the custom field too.
So I thought I would try to examine what exactly RT is receiving in either
case and see what is different. I am trying to familiarize myself with the
code, and I gather that I should be able to look at the request from one f
the lib/RT/Interface files, but I am not sure.
The RT Wiki is very helpul. Links like these may help:
http://rt.bestpractical.com/view/CleanlyCustomizeRT
http://rt.bestpractical.com/view/Debug
…and many others…
Have any of you had a need to examine an http request coming into RT and if
so can you tell me how to do this?
Sure, just printing out the params and headers should suffice for mist
problems. use Data::Dumper; warn Dumper($foo) is a also a usual
brutally effective way to peek into things.