Json, XML-RPC, SOAP and TurboGears

In the TurboGears book we focused on building web applications, but TurboGears is equally useful for creating web services.

It is remarkably easy to use TurboGears to respond to requests, with JSONified data. TurboGears automatically turns python dictionaries into JSON so you can write something like this:


@expose(template=.templates.hello)
@expose(allow_json=True)
def hello:
    return dict(title="Some title", body="Some body")

In the above method, If the request comes in from the browser with a tg_format parameter equal to ‘JSON’ the method will return JSON. If not the hello.kid template file will be used to render an HTML response. This means the same method can be used to handle user actions via AJAX or regular HTML, which is particularly handy if your application needs to degrade gracefully when the browser doesn’t support JavaScript.

But, there’s no reason you can’t use JSON and REST as web service type interface. In fact this is now my proffered way to expose “web services.” JSON is lightweight, clean, and has good implementations in multiple languages, and REST is a simple, elegant, and powerful way to organize your requests.

Even thought I prefer JSON and REST, the fact of the matter is that sometimes you need to talk SOAP or XML-RPC — because that’s what the system on the other end talks. This part of TurboGears isn’t as shiny and polished as the JSON story above, but it’s still pretty easy.

You can use TurboZSI to talk SOAP. The documentation could be better, but this is actually pretty cool. You can define

You can write your own XML-RPC Handler in less than 25 lines of code. And there’s a ticket in the TurboGears track system to make using XML-RPC work more like JSON.

There have been some rumblings about polishing all of this up and making Web Services a more integrated part of the TurboGears story. To me that sounds pragmatically wonderful. We shouldn’t stick our noses up and refuse to play when “enterprise” technologies show up.

Sure, there may be a better way, but playing nice means adapting to the people around you. There’s a lot we can learn from Rails, but as far as I’m concerned Rails can keep their “the anti-enterprise framework” rhetoric for themselves.

Instead, TurboGears should be the “easy to use, easy to extend framework” that plays nice with others, and makes the enterprise better and more fun.”

4 Responses to “Json, XML-RPC, SOAP and TurboGears”


  1. 1damjan

    “You can use TurboZSI to talk SOAP. The documentation could be better, but this is actually pretty cool. You can define”

    You can define. what?? It seems something is missing there.

  2. 2Joel

    Is there any way to have TG support a Pyro server? In other words, could CherryPy double as both an HTTP request handler AND a Pyro daemon? I am interested in exposing some functionality from a TG application to Pyro clients – attempting to avoid web services altogether since there is no need for language neutrality (I’m using python on both client and server).

  3. 3Joel

    so, other than using java2wsdl, is there an ‘easy’ way to generate wsdl for use with turboZSI from, say, a simpler, more direct language (like python) to describe the methods and parameters? I am starting to think I’ll just use java2wsdl to get a first cut WSDL file and then go from there with the ZSI stuff. The WSDL, after all, should be language neutral, no?
    If not, then what am I missing here?

  4. 4Jerry Spicklemire

    Re. WSDL, if one must, isn’t transformation via XSLT the canonical mode for all things rendered as XML? Of course, you have to generate suitable output, and create the templates, but there are many Python tools to help. See libxml2, Elementree, and the 4suite and Amara goodies from Uchi and co.

Comments are currently closed.