Difference between revisions of "Sudo API"

From Sudo Room
Jump to navigation Jump to search
(adds validator link)
 
(2 intermediate revisions by one other user not shown)
Line 2: Line 2:


==Software Stack==
==Software Stack==
* Gitorious repo:
* Gitorious repo: [https://gitorious.org/+sudo-room/sudo-api/sudo-api https://gitorious.org/+sudo-room/sudo-api/sudo-api]
* Software overview:
* Software overview:
** Python
** Python
Line 54: Line 54:
** type (string, optional) - mime-type of the feed (implementors should not rely on auto-detection of their feed type and are advised to provide this optional field)
** type (string, optional) - mime-type of the feed (implementors should not rely on auto-detection of their feed type and are advised to provide this optional field)
** url (string, mandatory) - url to the feed content
** url (string, mandatory) - url to the feed content
[[Category:Projects]]

Latest revision as of 15:52, 13 December 2012

The Sudo API is a project to serve and receive programmatic data for and about sudo room. This layer should act as an intermediary with every other relevant Sudo Room application. It speaks REST (in many formats, read more about the browsable API), is written in python with Django, and has a full API schema specification below.

Software Stack

API Specification

0.1

Status object

  • api (string, mandatory) - '0.12'
  • space (string, mandatory) - name of the hackerspace;
  • logo (string, mandatory) - url to a png, jpg or gif image;
  • icon (array, mandatory) - provides url's to 2 icons to use to depict 'open' and 'closed' status:
    • open (string, mandatory): url to a square png file with a max resolution of 100x100 pixels;
    • closed (string, mandatory): url to a square png file with a max resolution of 100x100 pixels;
  • url (string, mandatory) - url to the hackerspace homepage;
  • address (string, optional) - visiting address;
  • contact (object, optional) - has the following subfields:
    • phone (string, optional) - phone number (in the form of +CCNNNNNNNNN, where CC is the countrycode);
    • sip (string, optional) - sip uri (eg. 'sip:gmc@pbx.sonologic.net'
    • keymaster (string or array of strings, optional) - phone number, or phone numbers of people able to open the space (for spaces where not all members can unlock the door
    • irc (string, optional) - irc channel in the form of 'irc://freenode/#revspace';
    • twitter (string, optional) - twitter account in the form of '@brenno';
    • email (string, optional) - general email address;
    • ml (string, optional) - public mailing list address;
    • jabber (string, optional) - jabber chatbox;
    • ... - additional fields may be added if needed (but please let the author know, so it can be added to the spec in order to achieve consistency across implementations).
  • lat (float, optional) - latitude
  • lon (float, optional) - longitude
  • cam (array of strings, optional) - webcam url(s);
  • stream (array, optional) - object indexed by stream type with url to stream as value (eg { 'mp4':'http\/\/etc...','mjpg':'....'})
  • open (boolean, mandatory) - 'true' if the space is currently open, 'false' if not;
  • status (string, optional) - additional free-form string to specify the 'open' status (ie, 'open for public', 'members only', ...)
  • lastchange (long int, optional) - seconds since epoch of last change in the open field;
  • events (array, optional) - array of recent check-in/check-outs or other relevant events the space wants to share (such as the fire-alarm).
    • Each entry in the events array has the following fields:
    • name (string, mandatory) - name or nickname of person or object associated with this event;
    • type (string, mandatory) - 'check-in' or 'check-out' (other values may be specified, but receivers of the object are not obligated to be able to understand these)
    • t (long int, mandatory) - time since the epoch for this event
    • extra (string, optional) - additional information
  • sensors (array of arrays, optional) - indexed by sensor type, where the following types have been defined explicitly:
    • temp (array of strings) - strings indexed by a mnemonic identifier, the string value should match the regular expression ^[-+]?[0-9]+(.[0-9]+)?[FCK]$
    • additional sensor types may be defined by the implementor, implementor is requested to share the definition for inclusion in this specification
  • feeds (array of objects, optional) - one or more feeds (rss, atom, ical, ..), where each entry has the following fields:
    • name (string, mandatory) - mnemonic identifier (blog, news, calendar, ...)
    • type (string, optional) - mime-type of the feed (implementors should not rely on auto-detection of their feed type and are advised to provide this optional field)
    • url (string, mandatory) - url to the feed content