[PATCH 16/51] settings: Add Django REST framework to the project

[Finucane, Stephen]

> Let's try to do have a more modern approach to this web thing. Having a
> separate API returning some JSON ensures a nice split between data and
> UI. This API can be both used withing the HTML pages, loading/updating
> data with AJAX, and from any other kind of client (say, it could replace
> the XML-RPC API patchwork currently has).
> 
> But for now, let's experiment on Series.
> 
> Signed-off-by: Damien Lespiau <damien.lespiau at intel.com>

-1 This series revolves around adding support for series parsing: this patch (and subsequent, related patches) focuses on adding a different, large and currently unrequired feature. This secondary feature should be done in a different series, as suggested previously:

  https://lists.ozlabs.org/pipermail/patchwork/2015-August/001417.html

Addressing your points from that previous mail:

> Of one of the main thing is being able to re-use the API entry points
> from the web page itself (say using jquery's ajax). That makes the UI
> much nicer to use and reduces what the server needs to do (no full page
> reloads).

AJAX is great, but it's not necessary for series support. I'm all for responsive applications (in all senses), but I have yet to see a complaint about patchwork's resource demands nor a user requesting the functionality that AJAX would provide. If you personally think patchwork then by all means, make it happen but do so in another series.

> It also forces us to think in terms of objects and methods and have a
> clear separation between the backend and frontend(s).

What does this give us, besides slightly nicer "architecture"? The end user won't see this, but they will see the bugs and design oversights that will inevitably be present. APIs are hard work and once they're out there there's no going back: we want to make sure the one we implement is "right". This is something that needs to be discussed in its own thread.

> Right now the
> XML-RPC API feels like a bunch of disjointed functions. We also mix the
> views with API and have a number of "random" API entry points as POSTS
> requests on view.

Now this is a real issue. However, why not fix this in another series rather than trying to replace something that is well working but perhaps not as clean as it could be? The XML-RPC API may need some work but there's nothing fundamentally wrong with it (RPC is not dead: it's just out of fashion).

In summary, while I understand what you're trying I think you're going about it the wrong way. There may be some valid reasons for using REST, but we are currently able to do patch support with XML-RPC and we can sure do series support the same way :)

Stephen