[Rt-devel] REST: differentiating errors by RT status.

[Dmitri Tikhonov]

Hi Jesse,

Looking at the problem some more, I realize that this cannot be done
because RT's REST implementation allows specifying multiple objects:

  ticket/show/1-3

The response contains one "RT code" and three "forms"[1].  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"[2],
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...

Comments?

  - Dmitri.

1. BTW, who came up with "forms"?  Is there a standard they are based
on?

2. http://www.oreilly.com/catalog/pwebserperl/

On Mon, 2006-07-31 at 13:32 -0400, Dmitri Tikhonov wrote:
> I only know of two clients:
> 
>   rt
>   RT::Client::REST
> 
> Are there more?
> 
>   - Dmitri.
> 
> 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  
> > > failure of
> > > 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  
> > > exist/
> > > (error-prone).
> > >
> > > Thoughts?
> > 
> > I like it, so long as it doesn't break existing clients ;)
> > 
> > Best,
> > Jesse
> > 
> > 
> > 
> > >   - Dmitri.
> > >
> > >
> > > _______________________________________________
> > > 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
> > >
> > 
> 
> _______________________________________________
> 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