assembl.views.api2 package¶
Submodules¶
- assembl.views.api2.attachments module
- assembl.views.api2.auth module
- assembl.views.api2.content_source module
- assembl.views.api2.discussion module
- assembl.views.api2.idea_content_link module
- assembl.views.api2.ideas module
- assembl.views.api2.notification module
- assembl.views.api2.post module
- assembl.views.api2.preferences module
- assembl.views.api2.synthesis module
- assembl.views.api2.timeline module
- assembl.views.api2.user_key_values module
- assembl.views.api2.votes module
- assembl.views.api2.widget module
Module contents¶
RESTful API to assembl, with some magic.
It is guaranteed NOT to be stable, as it mirrors the model by introspection.
The basic URI to access any ressource is
GET /data/<Classname>/<instance db id>
The local: uri prefix is meant to resolve to <http://servername/data/>.
The other endpoints follow the pattern
/data/<classname>/<instance id>(/<collection name>/<instance id>)+
So we speak of class, instance or collection context, depending where we are in the URL.
It is generally possible to PUT or DEL on any instance context, and to POST to any class or collection context. POST will return a 201 with the link in the body in the Location response header.
The set of collections available from an instance type is mostly given by the SQLAlchemy relations (and properties),
but there is a magic URL to obtain the list:
/data/<classname>/<instance id>(/<collection name>/<instance id>)*/@@collections
Another special case is when the collection name is actually a singleton.
In that case, one is allowed to use - instead of a database ID which one may not know.
A final special case is the collection /data/Discussion/<N>/all_users, which has a shortcut to the logged-in user,
if any: /data/Discussion/<N>/all_users/current
This module defines generic behaviour, but more specific views can be defined
through new view predicates: Look for add_view_predicate at the end of assembl.views.traversal, and there is an example in
the widget collection view in assembl.views.api2.widget.
Note that the view_config must have at least as many specifiers as the one it tries to override!
Permissions for the default views are specified by the crud_permissions class attribute, but more specific
views may have their own permissions system.
For that reason, it will be generally useful to POST/PUT through collections accessed from the discussion, such as
/data/Discussion/<number>(/<collection name>/<instance id>)+
as opposed to the bare URLs /data/<Classname>/<instance db id> which are provided after a POST.
Traversing the discussion allows the user permissions specific to the discussion to be applied to the next operation.
The structure of those collection URLs will have to be reconstructed (from the POSTed collection, add the ID from the bare URL.)