Version 26 (modified by Fran Boon, 16 years ago) ( diff )

Done Deal :)


This page hosts detailed specifications for Blueprint for the RESTful API.

Basic approach for the S3 architecture is to have a Web Services backend & a Javascript client front end. RESTful APIs make this easier.

Web2Py generates URLs in this format:


These are generally used in a slightly RESTful way anyway (resources are URLs), e.g.:

/sahana/gis/features          # List_add

We have changed to URLs like these (see BluePrintRESTImplementation):

/sahana/gis/feature           # Acts as 'list' (or list_add if t2.logged_in)
/sahana/gis/feature/id        # Acts as 'display'

we could potentially do these:


but T3 requires ID to be the last argument, so don't want URLs like: /id/create

These are the benefits:

  • Consistency & ease of implementation of all basic functionality for new tables.
  • Simplified ability to create .represent widgets:
    def shn_list_item(table,resource,action,display='',extra=None):
        if extra:
        return DIV(*items)

We want to extend this to export raw data in other formats, e.g. using the optional vars:


or another arg:


Web2Py already supports export as JSON, CSV & RTF.

It would be best for us to add support to the framework to make it easy for module writers to have this functionality within their controllers.

NB Web2Py currently doesn't support HTTP PUT/DELETE/UPDATE (only GET).
This means a little work in clients but isn't too bad if we maintain consistency: no variations between add/create, view/display, edit/update, etc

Discussion of changes to Web2Py to make it more RESTful:

Web Services

Allows multiple client UIs

REST instead of SOAP

Less bloat, more GIS-friendly.

Python REST Servers

Python REST Clients

Javascript REST clients

Other REST clients

Note: See TracWiki for help on using the wiki.