Hi Alan, Me too! :)
My only comment on the v1/role is that it makes the path longer..I get its semantic rationale but am wondering if we need it yet. Cheers, Chris ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Chris Mattmann, Ph.D. Chief Architect Instrument Software and Science Data Systems Section (398) NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 168-519, Mailstop: 168-527 Email: [email protected] WWW: http://sunset.usc.edu/~mattmann/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Adjunct Associate Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -----Original Message----- From: "Alan D. Cabrera" <[email protected]> Reply-To: "[email protected]" <[email protected]> Date: Sunday, March 22, 2015 at 7:56 PM To: "[email protected]" <[email protected]> Subject: Re: Some initial stabs at a REST API > >> 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 >
