REST: differentiating errors by RT status

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?

  • Dmitri.

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 :wink:

Best,
Jesse

PGP.sig (186 Bytes)

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 :wink:

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

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 :wink:

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