Tapioca is a small and flexible micro-framework on top of Tornado. It provides a simpler way to create RESTful API's.
Create APIs using Tornado is easy, but Tapioca makes it even easier. Tapioca provides common behaviour to manage resources as close as possible to the definition of your RESTful API.
Tapioca also provides many different encoders enabling your resource to be easily serialized in different formats.
It´s incredibly easy to respond in a format that your API clients can understand.
Doesn't matter if they are a machine or a human being.
Tapioca gives you an automatic console interface to your API. This way it can be used as both the documentation and testing interface by your API clients.
Here is a "Hello, world!" example API written using Tapioca:
import tornado.ioloop
import tornado.web
from tapioca import TornadoRESTful, ResourceHandler
class HelloResource(ResourceHandler):
def get_collection(self, callback):
callback("Hello, world!")
api = TornadoRESTful(discovery=True)
api.add_resource('hello', HelloResource)
application = tornado.web.Application(
api.get_url_mapping()
)
if __name__ == "__main__":
application.listen(8888)
tornado.ioloop.IOLoop.instance().start()
This is the simplest usege of Tapioca. That provide the very basic features which is available to you.
With the code above you running you can access the hello route of your application.
$ curl -XGET -v -H "Accept: application/json" http://127.0.0.1:8888/hello
$ curl -XGET -v -H "Accept: text/javascript" http://127.0.0.1:8888/hello
$ curl -XGET -v -H "Accept: text/html" http://127.0.0.1:8888/hello
Or you can use extensions to force different content types.
$ curl -XGET -v http://127.0.0.1:8888/hello.json
$ curl -XGET -v http://127.0.0.1:8888/hello.js
$ curl -XGET -v http://127.0.0.1:8888/hello.html
Those are the default content types which Tapioca gives you.
All API's need to define parameters which users can query data or send other informations to the server. Tapioca provides a simple way to define and validate the data sent by your users. Those definitions will also be used later to introspect your API. The definition of which parameters do you expect in a specific route should be defined as follow:
...
from tapioca import validate
class HelloResource(ResourceHandler):
@validate(querystring={'name': unicode})
def get_collection(self, callback):
name = self.values.querystring['name']
callback("Hello, {}!".format(name))
...
As you can see in the code above, it's clear that the route expect to receive a parameter
'name' which is a unicode
value. It expect an unicode value because all parameters sent
to Tornado in a query string is a unicode value.
For parameter definition and validation Tapioca uses Schema
a pythonic library to define what values are accepted by your API. An example of an interger parameter
would be { 'parameter_name': Use(int) }
this way the value of parameter_name
will be converted
in an integer value. If it fails, an error will be raised and your API will return an error response.
You can also need that some parameters to be optional or maybe have default value when the parameter is not sent by
the users. Tapioca provide to you a way to declare it using the optional
function as follow:
...
from schema import Use
from tapioca import validate, optional
class HelloResource(ResourceHandler):
@validate(querystring={
'name': unicode,
optional('page', default_value=1): Use(int)
})
def get_collection(self, callback):
name = self.values.querystring['name']
page = self.values.querystring['page']
callback("Hello, {}! It's page {!s}.".format(name, page))
...
The example above shows how to define a parameter named page
with the default value 1
if
it is not present in the query string of the user request. If it's present the value will be used to
call the function int
as declared in the definition. We used the int
built-in function, but
you can use any callable object. We recommend you to read the Schema documentation for details.
To be make the code more readable Tapioca accepts as parameter in the validate
decorator an
class that defines the attribute querystring
as you can see below. The only requirement is that
class should inherits from RequestSchema
.
...
from schema import Use
from tapioca import validate, optional, RequestSchema
class SayHelloRequest(RequestSchema):
querystring = {
'name': unicode,
optional('page', 1): Use(int)
}
class HelloResource(ResourceHandler):
@validate(SayHelloRequest)
def get_collection(self, callback):
name = self.values.querystring['name']
page = self.values.querystring['page']
callback("Hello, {}! It's page {!s}.".format(name, page))
...
You can easily make your API speak a new "language".
Implementing your own encoder can be achieved in a few steps:
- Create a python class that inherits from
tapioca.Encoder
; - Override both
encode
anddecode
methods; - Provide some metadata about your new encoder by specifying its
mimetype
andextension
.
Below is a example of an encoder that enables responses as yaml data.
import yaml
from tapioca import Encoder
class YamlEncoder(Encoder):
mimetype = 'text/yaml'
extension = 'yaml'
def encode(self, data):
return yaml.dump(data)
def decode(self, data):
return yaml.load(data)
Using this encoder in your resources is as easy as including it in the
encoders
attribute in the respective ResourceHandler
s.
from tapioca import ResourceHandler
class CommentsResource(ResourceHandler):
encoders = ResourceHandler.encoders + (YamlEncoder,)
# ...
Now you can access your route and see it working:
$ curl -X GET http://localhost:8000/comments.yaml
To contribute with the Tapioca you can just fork the project, implement all the changes you need and then send us a pull request. It's important to make consistents pull request's. This means that every new feature should be in a separated pull request, in order to give us the possibility to review them separately (comments and feedback as well). We are open to suggestions and to discuss all your ideas.
Tapioca is licensed under the MIT License:
The MIT License
Copyright (c) 2012 globo.com lambda@corp.globo.com
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.