Tammo van Lessen wrote:
A REST API is far too big a system to even remotely consider including in the already bloated (IMO) Trac core. You can have an extension point within your plugin, and I'm not sure what code you thing needs to be duplicated. Maybe getting the model object from a URL, but thats about it. Thats pretty simple in most cases anyway. This is a perfect use-case for a plugin.Noah Kantrowitz wrote:That's great. Is there an example somewhere around? Nevertheless it will result in duplicating a lot of code. It's great to hear that it is possible, however from an architectural point of view I believe that it should be part of the core, exposing extension points for different representations. Speaking with the terms of fowler: making trac the front/application controller, externalizing the view rendering into plugin components).Tammo van Lessen wrote:IRequestFilter exists for exactly this reason, and can reroute requests without any changes to the original handler.Noah Kantrowitz wrote:Unless you can cite something specific, this is generally an incorrect assumption.That's why I said 'assume' and not 'claim' ;) The idea of REST includes that a resource has always a single identifier (i.e. URL), no matter which representation is rendered. That means that trac (or a plugin) would need to look at the content negotiation header of the request to then dispatch to a particular representation (be it HTML, RSS, Atom, CSV, JSON..) of this single resource. If there is a way to hook in a plugin that overrides the implementations of IRequestRequestHandler in each trac component (e.g. ticket, wiki,...) to support other representations as well as support for PUT and DELETE it would be certainly possible to write a plugin for such stuff. I just had a quick look at IRequestHandler and it implementation for tickets and I've got the impression that implementing REST is not that easy and not possible without modifying the core. Please correct me if I'm wrong.
--Noah
signature.asc
Description: OpenPGP digital signature
