Re: REST-API /summary

Hi Ralf:

In message <[email protected]>,
Ralf Schlatterbeck writes:
>The current REST-API has a hard-coded /summary endpoint that displays
>a summary of open issues. The class and query to use is hard-coded.
>
>Now I do run several trackers where we either don't have an issue-class
>at all or have several issue-like classes, 'issue' being just one of
>them.
>
>So what is displayed as the summary should probably not be hard-coded.
>Now before I implement something that later has to be changed: Should we
>make this configurable in config.ini? We currently *do* have the default
>class for the mail gateway in config.ini (which by default is 'issue'),
>we could uses something similar for the rest-api but would need some
>more configuration to specify the query to use.

Providing a setting for the default class may be a good idea. However
beter would be allowing the summary class to be overridden.

At the very least the implemetaion of the summary function needs to be
wrapped in a try/except block. This way if the "issue" class doesn't
exist the code returns a 400 with the payload:

 { data: {error: "/summary not supported in this schema" }}  

I am ok with either. I like the idea of /summary as an example.
I think trapping errors and returning 400 is the beter alternative.

>Ideas, Wishes?
>
>Or should we drop the /summary altogether?
>(would be my favourite)

I think keeping summary as an example, but making it overidable would
be good.

Is there a way from a tracker instance (maybe in interfaces.py) to
override or add methods in the RestfulInstance class?

--
				-- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.