> On Mar 18, 2015, at 5:28 AM, Daniel Gruno <[email protected]> wrote: > > Hi folks, > I was looking at Chris' REST API suggestions (still don't have wiki karma ;( > ) and it got me fiddling with some python CGI to start making election and > issue creation/editing available via the web. As it is now, it's just a > method for setting up an election and issues, as well as viewing them via > JSON objects. There is no authentication going on or anything like that. > > Some example output from the API: > http://stv.website/steve/voter/view/foo > http://stv.website/steve/voter/view/foo/baz > etc etc. > > If the idea seems reasonable, I would _love_ to collaborate with folks on > getting this up and running as an idea for a Steve 2.0. I'll be making some > HTML/JS stuff so you can set up and edit stuff without having to use curl for > the API in a day or so. > > The current API I'm using is described in REST_API_README.txt under pytest/.
I’m pretty excited about this! You may want to watch Les Hazlewood’s lecture on "Beautiful REST & JSON APIs": https://youtu.be/mZ8_QgJ5mbs <https://youtu.be/mZ8_QgJ5mbs> The video is an excellent lecture on the finer points of REST API design. Some things that I usually do w/ my API is prefix the API with /api/v1/<role>/… The v1 bit is obviously the version number. The <role> bit specifies who has permission to access that path. It makes it a bit easier to setup protection by path and it’s obvious what you’ll get back. I like to do this even if the suffix after the role is repeated across roles. I wonder what others think of this convention. Regards, Alan
