Tuesday, January 29, 2013

Using Thrift IDL as a Rest Interface Definition Language

Deriving a thrift idl file from existing code: Using python introspection can produce a thrift interface definition file from class members and methods. It could also be a natural way to describe rest services in the native language. One could then use this file to generate restful services boilerplate code on a target web platform of your choice for example django.

 I have a module called introspection that uses inspect to fetch class methods as well as their argument specs in a way that could produce python code that calls these methods with the correct imports. The module retrieves members as well. I would like to use this to transform nltk.corpus.reader.wordnet members into rest services and I will use this as the base for writing a thrift definition file from. I would also like to define my rest services as a python class RestServices and have the thrift file automatically generated along with
the skeleton django project.

Thrift can define enumerated constants, structs, complex structures in the form of json constants. I plan on using these to define the object types that I will then serialize and deserialize using either the thrift transport stack or jsonpickle. The aim being to make rest post requests with serialized json objects in the request headers that will form parameters to rest functions and produce objects in the service code. 

These functions will then return json responses that might contain standard exception structures.

The django specific build instructions will be placed in the doc style comments in the thrift file. Every method will have doc style or inline comments that will contain base uri and project specific instructions will also be stored using doc style comments.

  • // @base_uri: wordnet/
  • /** @target django
  •  *   @project myproject
  •  *   @app myapp
  •  *   @settings path/to/my/settings.py */

 I will generate a django skeleton with url mappings starting with "/wordnet/method_name" and use the comments to build the skeleton django project.

The frontend javascript application interface will enable you to call rest methods to produce json objects stored in the client side javascript container. You will also be able to make changes to these objects. You will then be able to use these objects as parameters to other rest methods.

I expect to run into a few hurdles especially when deriving method parameter structs as python isn't a typed language. I thought about using a semantic approach to determining which functions produce the expected object and using runtime introspection to produce the structure definition.

This is because I believe in harnessing the thought processing that goes into choosing names.

In cases where this is not possible a notification to review the definition file will be raised. The definition file will always need to be reviewed anyway right.

This implementation just serves to use introspection and semantics to the best of their abilities to produce a base definition to work from. I'm designing this with other frameworks in other languages in mind to make it possible to produce cakephp rest skeleton projects. The running name for this project is restify.