On 5/29/13, Antonia Horincar <[email protected]> wrote: > Hi, >
:) > On Tue, May 28, 2013 at 9:54 PM, Olemis Lang <[email protected]> wrote: [...] >> >> Yes , during the last few days I've been thinking of ways to improve >> RestOnTrac plugin and I'm working now (and will be suring the next few >> days) towards version 2 of the API . This means you'll get these >> answers asap , and I'll be accepting both feedback and patches based >> on your work . >> >> What will be your starting point ? ... so that I can manage priorities >> ... >> > > Thank you for your reply. Since I still don't know very much about > RestOnTrac's structure, I can't tell for sure what will be my starting > point for the back-end part. I meant to ask this : Will you start with embedding ticket data in external sites ? or maybe some other data hosted by Bloodhound ? ... which one ? > This is why I would appreciate some > explanation on the plugin's internal structure. > I'll provide these asap . Nevertheless in a few words , API v2 will be very similar to django-piston i.e. a Resource class with methods for CRUD operations , and routes definitions in the fornt-end >> PS: I've also been thinking of many other nice improvements too ... in >> the fridge ... >> ;) >> [...] > > Also, I want to share what Shiva Teja (also a member of this mailing > list) suggested to me yesterday. He wanted to share with me his idea > on implementing the back-end of the project, which implied using > IRequestHandler The RestModule class already implements IRequest handler to process HTTP requests ... > for dealing with web requests and the TracTicketSystem > class to get the content of a specific ticket. ... and (will) provide wrappers and helpers to reuse (tested) BloodhoundRPC handlers retrieving data hosted by the environment (i.e. not just tickets), assert permissions , pluggable API authentication methods , etc ... > Can anyone give some > feedback on this, as I want to make a comparison between this approach > and the one involving RestOnTrac, and choose the best one? > You could do everything from scratch , or reuse REST and/or RPC backend . I'll prioritize working and testing ticket REST endpoint of the API and come back to you with further details . >From the perspective of API consumers you'll retrieve the (XML | JSON | YAML | ...) representation of ticket 123 by issuing an HTTP GET request to /api/ticket/123 [...] -- Regards, Olemis.
