ladon 0.9.24

Description

Ladon is a framework for exposing python methods to several internet service
protocols. Once a method is ladonized it is automatically served through all
the interfaces that your ladon installation contains. Ladon is easily extendable.
Adding a new service interface is as easy as adding a single module containing
a class inheriting the BaseInterface class.

Example

from ladon.ladonizer import ladonize
class Calculator(object):
"""
This service does the math, and serves as example for new potential Ladon users.
In-line documentation ends up in the web service online browsable API
"""
@ladonize(int,int,rtype=int)
def add(self,a,b):
"""
Add two integers together and return the result
@param a: 1st integer
@param b: 2nd integer
@rtype: The result of the addition
"""
return a+b

Follow

Questions

Bugs

Contribute

There are plenty of things to do like implementing more interface modules making better service navigation etc. If you are interested in helping out with contributions or even want to join the development team - Go to Ladon’s Launchpad page: http://launchpad.net/ladon

What does Ladon mean?

Ladon is a serpent-like dragon from Greek mythology which might be given multiple
heads, a hundred in Aristophanes’ The Frogs (a passing remark in line 475). each
head might speak with different voices.

Like Ladon the dragon has many heads that speak with different voices Ladon the
Web Service has many interfaces that communicate with different protocols. Ladon
the dragon only has one body - users only need to implement their service
classes once.

Changes

New in 0.9.24

BUGFIX: Probed Language should not be passed to interface description method

New in 0.9.23

Added LADON_ACCEPT_LANGUAGES to keyword args, service methods can use this to get a list of languages accepted by the user.

New in 0.9.11

New in 0.9.10

New in 0.9.9

Fix: Version 0.9.0 broke Python 3 support. This has now been fixed and tested with Python 3.4

New in 0.9.8

Finally introducing Tasks. Earlier on it has been announced that task-type Ladon methods would be the
feature that brings Ladon to version 1.0.0. Indeed that will be the case, but this is kind of a technology
preview.

Cave-eats:

Uses the threading module meaning that GIL is in play

Task state is kept in global python variables and therefore do not work cross-host nor cross-process

In many use-cases these cave-eats are not a problem. Ie. if your task spawns a new synchronious process
like a system-call you will not be having problems with GIL and the current implementation will work as
long as your application stays within the same process.

The good thing about the current solution is that it works out-of-the-box without introducing thirdparty
state-keeping services. It should also be noted that if you are using ie. mod-wsgi on apache2 it is
possible to control process groups for specific Ladon services, so you can configure your apache server
to use only one process for your services containing task type Ladon methods, and multiple procesesses for
your other services that do not need to keep state like Ladon tasks.

The solution for the cave-eats mentioned will be the option to configure socket-based state caching like
memcached or redis. If using the thirdparty state caching option Ladon will shift over to using the
multiprocessing module for task execution. This solution should solve both cave-eats and will be when
Ladon turns into 1.0.0.

The current implementation will probably stay in Ladon because it is very easy to use and requires no
extra configuration other than the keyword in your ladonize decorator - example:

New in 0.7.2

Added the possibility to use choose between different publishing types when writing
inline documentation for the online API documentation. Possible publishers are “raw”,
“pre” and “docutils” - Example:

New in 0.7.1

Fixed bug 974655
Added via proxy feature to the Python jsonwsp client

New in 0.7.0

Fixed bugs 926442 and 926445

New in 0.6.7

Attribute filtering is a new feature that allows the service developer to define functions
that can be triggered before and after a service method has been executed. Filter functions
can be used to validate or modify attribute values.

New in 0.6.6

New dictionary based type-definition for LadonType attributes. Until version 0.6.6 all
LadonType attributes had to reference a type or list of type directly. With dictionary type
definitions it is possible for the service developer to pass more detailed properties about
attributes, like documentation lines, default value or whether it is nullable (None) or not.
Old-style LadonType attribute definitions are still valid and therefore this change offers
backwards compatability. The integration of nullable is built into the soap and jsonwsp
interfaces. Example:

New in 0.6.5

Fault handling finally implemented. interfaces must now implement a FaultHandler inheriting
the BaseFaultHandler class. Fault handlers have been implemented for both SOAP and JSONWSP
interfaces.
All exceptions that occure under method invocation are caught by Ladon’s dispatcher and
sent to the interface fault handler. Use ServerFault or ClientFault exceptions implemented in
ladon.exceptions.service to raise either a server fault or to blame a fault on the client.
Other exceptions that might occure under service method invocation are viewed as unmanaged
Server Faults, and converted to such by the dispatcher.

New attachment reference format cidx:<index>. This format let’s the client post request that
have references to attachment parts by index rather than Content-Id.

New in 0.6.4

JSONWSPClient __init__(description=None,url=None) takes description url as first argument or
keyword “description”. A new keyword argument “url” can be passed instead of description if
the jsonwsp API is known. The tradeoff of using the url is that there are not created any
placeholder methods on the JSONWSPClient object, instead you must call methods via the
call_method() method.

CustomResponse - Ladon now offers the ability to define custom response on specified methods.
For instance you can make Ladon respond with a browser download response on a specific service
method. Example:

New in 0.4.8

New in 0.4.7

Service Navigation: Better browser navigation for services. New features
are full service documentation with CSS-styled browsable interface.

Much more documentation

New in 0.4.6

Added export_dict to the dispatcher. Values from this dict will be exported
to ladonized methods if they have **kw at the end of their parameter list.
By default the LadonWSGIApplication will export WSGI’s environ.

New in 0.4.4

Added a JSON-WSP python client: misc/jsonwsp/jsonwspclient.py. The client
can be integrated into other python modules using the JSONWSPClient class,
but it can also be run as a shell command.

New in 0.4.3

New feature called mirror/reflection especially designed for asynchronious
client/server communication to keep track on the client which responses
belongs to which requests. For example a request ID can be mirrored by the
server and reflected back to the client, so it is possible to map many
simultaneously incomming responses that are handled by the same function.

Ladon documentation for the dispatcher

New in 0.4.2

Fixed bug that made incomming booleans always resolve to True

Ladon documentation for collection and typeconverter

New in 0.4.1

Added LGPL License.txt in the root of the project

Ladon documentation for ladonize

New in 0.3.7

jsonwsp.spec file added to the repository.

jsonwsp description specification very near 1.0

Bug-fix in wsgi_application.py charset detection moved to the first action
when a request is recieved.

New in 0.3.6

jsonrpc interface renamed to jsonwsp, short for JSON Web Service Protocol.
This was decided to prevent confusing whether Ladon’s json-based protocol
supports the json-rpc specified in at: http://json-rpc.org/. Ladon’s json-
based protocol is clearly inspired by json-rpc, but is not the same.

jsonwsp response, request and description formats has been altered to contain
‘type’ and ‘version’ values.