aiorest
aiorest copied to clipboard
aio-libs-abandoned
custom response serialization
I think request handler should return dict instance. The instance should be converted into binary data by some processor (you can call it serializer or renderer). Processor should support template engines (I mean jinja2 for example).
Do you mean that handler should return something like: {'foo': 'bar', '__processor': 'jinja2'} ?
No, I don't like to return processor name from handler.
My vision is closer to:
@renderer(template='page.jinja2')
def handler(request):
return {'foo': 'bar'}
So it's the current way with some decorator's sugar? But what about html or binary (eg pictures) data? Why we have to wrap it into a dict?
Hi,
I'm sorry @asvetlov, but I prefer the solution of @imbolc, because it's simple and easy to customize for our needs. We make WebServices REST/JSON oriented, but sometimes, we need to generate XML, SOAP or a very ugly format you don't want to know that it exists, because our clients are blocked with a specific piece of software. Moreover, maybe you'll receive a Pull Request to define routes via a decorator. It means you'll have:
@server.add_url('GET', '/hello')
@asyncio.coroutine
@renderer(template='page.jinja2')
def handler(request):
return {'foo': 'bar'}
Maybe should be better to try to reduce the number of decorators, it's harder to debug.
(FYI, we already use aiohttp on production, and we want to replace our WebServices, based on Flask, by something based on aiohttp, because the performances are better with aiohttp. For now, aiorest is a good candidate for us)
Moreover, we have another scenario that doesn't fit with decorator: For some WebServices, we read "Accept" header to know if we push a XML or JSON document.
@imbolc: FYI, I've merged your PR in our aiorest fork: https://github.com/Eyepea/aiorest
