[core-workflow] bugs.python.org-related GSoC project

[Nick Coghlan]

On 17 March 2015 at 01:36, Barry Warsaw <barry at python.org> wrote:
> On Mar 16, 2015, at 09:52 PM, Nick Coghlan wrote:
>
>>I've found one neat trick for this kind of scenario is to devise
>>standalone projects that are likely to be useful regardless of what
>>happens in the broader context. REST-API-in-upstream-Roundup
>>qualifies
>
> As Nick knows, we've had great success with REST in Mailman 3.  Having a REST
> API for Roundup would be very cool, and given our experience it feels
> GSoC-sized in effort, especially including the filling out of a robust API.

I actually need to take an internal email I wrote regarding the
definition of the overall REST API design for beaker-project.org and
turn it into a public blog post. I believe the reason "REST backend,
JavaScript client front end" works so well is that it lets you have a
single "implementation model" (the REST web service) that exposes the
raw data model in a form that's easy for *developers* to work with,
while supporting multiple "representation models" that different
groups of users interact with (your JavaScript UX, command line tools,
UI elements in other web services):
http://uxoslo.com/2014/01/14/ux-hints-why-mental-models-matter/

In the case of Roundup, the data model is actually very REST friendly,
as the existing XML-RPC interface already embodies the "collections of
resources" approach. In theory, it should "just" be a matter of
exposing those collections through an appropriate set of APIs (and
figuring out things like access management, etc).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia