On 17 March 2015 at 01:36, Barry Warsaw <[email protected]> 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 | [email protected] | Brisbane, Australia _______________________________________________ core-workflow mailing list [email protected] https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct
