webdb.interface

webdb.interface.db

Web interface for databases using JSON requests.

class webdb.interface.db.DBInterface(dbms)

Interface for databases.

In the current version both GET and POST behave the same way but this might be changed in the future.

This will try to fulfill the request and return either nothing (Status = 204), plain text (Status = 200, Content-Type = text/plain) or JSON (Status = 200, Content-Type = application/json).

On failure (Status = 400 or Status = 404) it will return a more or less helpful error message (Content-Type = text/plain).

webdb.interface.file

Web interface for file access.

class webdb.interface.file.DispatchedFile(dispatcher, inject, nickname)

This is the class that actually serves a file. See the documentation of FileInterface, about the usage.

class webdb.interface.file.FileInterface(dispatcher, inject)

Serves files. A HTTP POST will write (a part of ) the file, HTTP GET will return (a part of) the file.

Interface:

Files are associated with a path. Assuming that the interface is mounted under /files, it will dispatch /files/foo/bar.baz to the path foo/bar.baz. This path is passed to the dispatcher instance and the actual FileOverlay will be dispatched.

One can delete the file using HTTP DELETE. If the argument ?truncate=<bytes> is supplied, the file will be truncated to <bytes>. NOTE: if <bytes> cannot be converted to an integer, the file will be deleted.

The file can be created expicily by using HTTP PUT.

One can receive (a part) of a file using HTTP GET. If offset is provided the file part will start at byte offset. If chunk_size is provided at most chunk_size bytes will be returned.

HTTP POST will set (a part) of a file. If offset is provided the file part will be written at offset. Content-Type must be application/octet-stream.

If the POST/DELETE/PUT request succeed Status 204 will be set. If GET succeeds Status 200 will be set and the (binary) file content will be returned. Content-Type in this case is application/octet-stream.

If any request fails Status 404 will be set and a (more or less) helpful error message will be returned. If an argument cannot be parsed properly Status 400 will be set and an error message will be returned.

The constructor argument inject is a callable that returns the second argument of the dispatcher’s dispatch_file. Usually this will be something like lambda: cherrypy.session["username"].

XXX: *NOTE*:

Youn MUST (!) add {'request.dispatch': cherrypy.dispatch.MethodDispatcher()} to your application config. If you forget that cherrypy will not be able to dispatch the methods properly.