¿Recomendaciones del framework REST de Python (servicios web)?

¿Hay una lista en algún lugar de recomendaciones de diferentes marcos REST basados ​​en Python para usar en el lado del servidor para escribir sus propias API RESTful? Preferiblemente con pros y contras.

Por favor, siéntase libre de agregar recomendaciones aquí. 🙂

Algo para tener cuidado al diseñar una API RESTful es la combinación de GET y POST, como si fueran la misma cosa. Es fácil cometer este error con las vistas basadas en funciones de Django y el despachador predeterminado de CherryPy , aunque ambos marcos ahora ofrecen una solución a este problema ( vistas basadas en clases y MethodDispatcher , respectivamente).

Los verbos HTTP son muy importantes en REST y, a menos que tengas mucho cuidado con esto, terminarás cayendo en un anti-patrón REST .

Algunos marcos que lo hacen bien son web.py , Flask y Bottle . Cuando se combinan con la biblioteca mimerender (divulgación completa: lo escribí), te permiten escribir servicios web RESTful agradables:

import web import json from mimerender import mimerender render_xml = lambda message: '%s'%message render_json = lambda **args: json.dumps(args) render_html = lambda message: '%s'%message render_txt = lambda message: message urls = ( '/(.*)', 'greet' ) app = web.application(urls, globals()) class greet: @mimerender( default = 'html', html = render_html, xml = render_xml, json = render_json, txt = render_txt ) def GET(self, name): if not name: name = 'world' return {'message': 'Hello, ' + name + '!'} if __name__ == "__main__": app.run() 

La lógica del servicio se implementa solo una vez, y la selección de representación correcta (Aceptar encabezado) + envío a la función de procesamiento (o plantilla) correcta se realiza de forma ordenada y transparente.

 $ curl localhost:8080/x Hello, x! $ curl -H "Accept: application/html" localhost:8080/x Hello, x! $ curl -H "Accept: application/xml" localhost:8080/x Hello, x! $ curl -H "Accept: application/json" localhost:8080/x {'message':'Hello, x!'} $ curl -H "Accept: text/plain" localhost:8080/x Hello, x! 

Actualización (abril de 2012) : se agregó información sobre las vistas basadas en clase de Django, MethodDispatcher de CherryPy y los marcos de Flask y Bottle. Ninguno de los dos existió cuando se hizo la pregunta.

Sorprendido nadie mencionó el matraz .

 from flask import Flask app = Flask(__name__) @app.route("/") def hello(): return "Hello World!" if __name__ == "__main__": app.run() 

Estamos usando Django para servicios web RESTful.

Tenga en cuenta que, fuera de la caja, Django no tenía una autenticación suficientemente precisa para nuestras necesidades. Utilizamos la interfaz Django-REST , que ayudó mucho. [Desde entonces, hemos rodado el nuestro porque habíamos hecho tantas extensiones que se había convertido en una pesadilla de mantenimiento].

Tenemos dos tipos de URL: las URL “html” que implementan las páginas HTML orientadas a las personas, y las URL “json” que implementan el procesamiento orientado a servicios web. Nuestras funciones de vista a menudo se ven así.

 def someUsefulThing( request, object_id ): # do some processing return { a dictionary with results } def htmlView( request, object_id ): d = someUsefulThing( request, object_id ) render_to_response( 'template.html', d, ... ) def jsonView( request, object_id ): d = someUsefulThing( request, object_id ) data = serializers.serialize( 'json', d['object'], fields=EXPOSED_FIELDS ) response = HttpResponse( data, status=200, content_type='application/json' ) response['Location']= reverse( 'some.path.to.this.view', kwargs={...} ) return response 

El punto es que la funcionalidad útil se factoriza fuera de las dos presentaciones. La presentación JSON es generalmente solo un objeto que fue solicitado. La presentación HTML a menudo incluye todo tipo de ayudas de navegación y otras claves contextuales que ayudan a las personas a ser productivas.

Las funciones jsonView son todas muy similares, lo que puede ser un poco molesto. Pero es Python, así que haz que formen parte de una clase llamable o escribe decoradores si te ayuda.

Ver la wiki de Python Web Frameworks .

Probablemente no necesite los marcos de stack completos , pero la lista restante es bastante larga.

Realmente me gusta CherryPy . Aquí hay un ejemplo de un servicio web tranquilo:

 import cherrypy from cherrypy import expose class Converter: @expose def index(self): return "Hello World!" @expose def fahr_to_celc(self, degrees): temp = (float(degrees) - 32) * 5 / 9 return "%.01f" % temp @expose def celc_to_fahr(self, degrees): temp = float(degrees) * 9 / 5 + 32 return "%.01f" % temp cherrypy.quickstart(Converter()) 

Esto enfatiza lo que realmente me gusta de CherryPy; Este es un ejemplo completamente funcional que es muy comprensible incluso para alguien que no conoce el marco. Si ejecuta este código, puede ver inmediatamente los resultados en su navegador web; Por ejemplo, visitando http: // localhost: 8080 / celc_to_fahr? degrees = 50 mostrará 122.0 en su navegador web.

Echa un vistazo a

  • Itty ( blog post )
  • Botella
  • web.py
  • juno

No veo ninguna razón para usar Django solo para exponer una API REST, hay soluciones más ligeras y más flexibles. Django lleva muchas otras cosas a la mesa, que no siempre son necesarias. Por supuesto, no es necesario si solo desea exponer algunos códigos como un servicio REST.

Mi experiencia personal, fwi, es que una vez que tenga un marco de talla única, empezará a utilizar su ORM, sus complementos, etc. simplemente porque es fácil y en ningún momento terminará teniendo una dependencia. Es muy difícil deshacerse de eso.

Elegir un marco web es una decisión difícil, y evitaría elegir una solución de stack completa solo para exponer una API REST.

Ahora, si realmente necesitas / quieres usar Django, entonces Piston es un buen marco REST para las aplicaciones de django.

Dicho esto, CherryPy también se ve muy bien, pero parece más RPC que REST.

Mirando las muestras (nunca lo usé), probablemente web.py sea el mejor y más limpio si solo necesita REST.

Aquí hay una discusión en los documentos de CherryPy en REST: http://docs.cherrypy.org/dev/progguide/REST.html

En particular, menciona un despachador de CherryPy incorporado llamado MethodDispatcher, que invoca métodos basados ​​en sus identificadores de verbo HTTP (GET, POST, etc.).

En 2010, las comunidades de Pylons y repoze.bfg se unieron para crear Pyramid , un marco web basado principalmente en repoze.bfg. Conserva las filosofías de sus marcos principales y puede utilizarse para servicios RESTful . Vale la pena echarle un vistazo.

Piston es un marco muy flexible para el cableado de APIs RESTful para aplicaciones Django.

Parece que todos los tipos de marcos web de Python pueden implementar interfaces RESTful ahora.

Para Django, además de tastypie y pistón, django-rest-framework es una promesa que vale la pena mencionar. Ya he migrado uno de mis proyectos en él sin problemas.

El marco REST de Django es un marco REST ligero para Django, cuyo objective es facilitar la creación de API web RESTful bien autenticadas y bien conectadas.

Ejemplo rápido:

 from django.conf.urls.defaults import patterns, url from djangorestframework.resources import ModelResource from djangorestframework.views import ListOrCreateModelView, InstanceModelView from myapp.models import MyModel class MyResource(ModelResource): model = MyModel urlpatterns = patterns('', url(r'^$', ListOrCreateModelView.as_view(resource=MyResource)), url(r'^(?P[^/]+)/$', InstanceModelView.as_view(resource=MyResource)), ) 

Tome el ejemplo del sitio oficial, todos los códigos anteriores proporcionan una API, un documento autoexplicado (como el servicio web basado en el soap) e incluso un sandbox para probar un poco. Muy conveniencia.

Enlaces: http://django-rest-framework.org/

No soy un experto en el mundo de python, pero he estado usando django, que es un excelente marco web y se puede usar para crear un marco de trabajo tranquilo.

web2py incluye soporte para crear fácilmente APIs REST, descritas aquí y aquí (video). En particular, mire parse_as_rest , que le permite definir patrones de URL que asignan argumentos de solicitud a consultas de base de datos; y smart_query , que le permite pasar consultas de lenguaje natural arbitrarias en la URL.

Si estás usando Django, entonces puedes considerar django-tastypie como una alternativa al django-piston . Es más fácil sintonizar las fonts de datos que no son ORM que el pistón, y tiene una excelente documentación .

Recomiendo encarecidamente TurboGears o Botella:

TurboGears:

  • menos verboso que django
  • Más flexible, menos orientado a HTML
  • pero: menos famoso

Botella:

  • muy rapido
  • muy facil de aprender
  • Pero: minimalista y no madura.

Estamos trabajando en un marco para servicios REST estrictos, visite http://prestans.googlecode.com

En sus inicios, Alpha en este momento, estamos probando contra mod_wsgi y el AppEngine de Google.

Buscando probadores y comentarios. Gracias.