Looking at the problem some more, I realize that this cannot be done
because RT’s REST implementation allows specifying multiple objects:
The response contains one “RT code” and three “forms”. If ticket 3
does not exist, the third form will contain a comment “ticket 3 does not
exist”. The first two will contain actual key/value pairs. While 2 out
of 3 ain’t bad :-), this means that the “RT code” is useless for my
purposes (detecting errors) and I have to parse comments in each form.
Other questions are whether ranges a) buy anything and b) are in
compliance with REST.
Looking at the server-side implementation, it looks like ranges are
expanded and then each of the expanded objects has the operation applied
to it in order, so this only buys the savings of HTTP overhead.
I am staring at chapter 11 of “Programming Web Services with Perl”,
but cannot find answer to (b). Thinking about “every resource has a
URI” principle, I think ranges introduce some ambiguity:
- is ticket/show/1-3 a resource by itself?
- is ticket/show/1-3 different from say, ticket/show/3,2,1? (they are
not according to rt 3.4.5 – both come back in 1-2-3 order)
- based on the above result, we see that the same resource has at
least 2 URIs (4 more: 1,3,2, 2,3,1, 2,1,3, 3,1,2).
- and so on.
RT::Client::REST is proving difficult to implement because the current
client/server REST implementation in RT is geared towards interactive,
not programmatic use (I judge by comments such as “We won’t pass $e
through to compose, trusting instead that the handler added suitable
comments for the user.” in the server-side code).
I am thinking about removing the ability to specify ranges in
RT::Client::REST APIs and forcing the user to do a loop – this way,
exceptions thrown can be easily correlated with a single object instead
of a range. I think consistency in the APIs is more important than
minimizing the number of HTTP requests…
BTW, who came up with “forms”? Is there a standard they are based
http://www.oreilly.com/catalog/pwebserperl/On Mon, 2006-07-31 at 13:32 -0400, Dmitri Tikhonov wrote:
I only know of two clients:
Are there more?
On Mon, 2006-07-31 at 12:34 -0400, Jesse Vincent wrote:
On Jul 28, 2006, at 9:31 AM, Dmitri Tikhonov wrote:
Dear fellow RTers,
I think that server-side REST code should indicate success or
operation by utilizing “RT code”. For example, fetching a ticket that
does not exist returns the following:
RT/3.4.5 200 Ok
Ticket 4 does not exist.
Maybe it should return
RT/3.4.5 404 Not Found
Ticket 4 does not exist.
So that the client can just know that something’s amiss by
looking at the
RT code (easy) instead of parsing output for things like m/does not
I like it, so long as it doesn’t break existing clients
List info: http://lists.bestpractical.com/cgi-bin/mailman/listinfo/
Best Practical is hiring! Come hack Perl for us: http://
List info: http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-devel
Best Practical is hiring! Come hack Perl for us: http://bestpractical.com/about/jobs.html