Recommandations du cadre Python REST (services web)? [fermé]
y a-t-il une liste de recommandations de différents cadres de repos basés sur Python à utiliser sur le serverside pour écrire vos propres API RESTful? De préférence avec des avantages et des inconvénients.
s'il vous Plaît n'hésitez pas à ajouter des recommandations ici. :)
16 réponses
quelque chose à faire attention lors de la conception D'une API RESTful est la combinaison de GET et POST, comme si elles étaient la même chose. Il est facile de faire cette erreur avec Django 's "function-based views et CherryPy 's dispatcher, bien que les deux cadres fournissent maintenant une solution à ce problème ( class-based views et MethodDispatcher , respectivement).
les verbes HTTP sont très importants dans REST, et à moins que vous ne soyez très prudent à ce sujet, vous finirez par tomber dans un REST anti-pattern .
certains cadres qui le font bien sont web.py , flacon et bouteille . Lorsqu'ils sont combinés avec la bibliothèque mimerender (divulgation complète: je l'ai écrit), ils permettent vous pour écrire de bons RESTful webservices:
import web
import json
from mimerender import mimerender
render_xml = lambda message: '<message>%s</message>'%message
render_json = lambda **args: json.dumps(args)
render_html = lambda message: '<html><body>%s</body></html>'%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 logique du service n'est implémentée qu'une seule fois, et la sélection correcte de la représentation (en-tête Accept) + envoi à la fonction de rendu (ou au modèle) est faite de manière ordonnée et transparente.
$ curl localhost:8080/x
<html><body>Hello, x!</body></html>
$ curl -H "Accept: application/html" localhost:8080/x
<html><body>Hello, x!</body></html>
$ curl -H "Accept: application/xml" localhost:8080/x
<message>Hello, x!</message>
$ curl -H "Accept: application/json" localhost:8080/x
{'message':'Hello, x!'}
$ curl -H "Accept: text/plain" localhost:8080/x
Hello, x!
Update (April 2012) : ajout d'informations sur les vues de classe de Django, le MethodDispatcher de CherryPy et les cadres de flacon et de flacon. Ils n'existent pas de retour lorsque la question a été posée.
N'a surpris personne n'a mentionné fiole .
from flask import Flask
app = Flask(__name__)
@app.route("/")
def hello():
return "Hello World!"
if __name__ == "__main__":
app.run()
Nous sommes à l'aide de Django pour les services web RESTful.
notez que -- Out of the box -- Django n'avait pas assez d'authentification fine pour nos besoins. Nous avons utilisé L'interface Django-REST , qui a beaucoup aidé. [Nous avons depuis roulé les nôtres parce que nous avions fait tellement d'extensions que c'était devenu un cauchemar d'entretien.]
nous avons deux types D'URLs:" html " URLs qui mettent en œuvre le les pages HTML axées sur l'humain, et les URL "json" qui mettent en œuvre le traitement axé sur les services web. Nos fonctions de vue ressemblent souvent à ceci.
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
le point étant que la fonctionnalité utile est prise en compte sur les deux présentations. La présentation JSON est généralement juste un objet qui a été demandé. La présentation HTML comprend souvent toutes sortes d'aides à la navigation et d'autres indices contextuels qui aident les gens à être productifs.
le jsonView fonctions sont toutes très similaires, ce qui peut être un peu ennuyeux. Mais C'est Python, alors faites-les participer à un cours callable ou écrivez décorateurs si cela peut aider.
voir Python Web Frameworks wiki.
vous n'avez probablement pas besoin des cadres full stack , mais la liste restante est encore assez longue.
j'aime CherryPy . Voici un exemple d'un service web reposant:
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())
cela souligne ce que j'aime vraiment chez CherryPy; c'est un exemple complètement fonctionnel qui est très compréhensible même pour quelqu'un qui ne connaît pas le cadre. Si vous utilisez ce code, alors vous pouvez immédiatement voir les résultats dans votre navigateur Web; par exemple en visitant http://localhost:8080/celc_to_fahr Je ne sais pas.degrés=50 s'affichera 122.0 dans votre navigateur web.
Je ne vois aucune raison d'utiliser Django juste pour exposer une api REST, il y a des solutions plus légères et plus flexibles. Django porte beaucoup d'autres choses à la table, qui ne sont pas toujours nécessaires. Pour sûr pas nécessaire si vous voulez seulement exposer un certain code comme un service de repos.
mon expérience personnelle, fwiw, est qu'une fois que vous aurez un framework Taille unique, vous commencerez à utiliser son ORM, ses plugins, etc. juste parce que c'est facile, et en un rien de temps tu finis par avoir la dépendance est très difficile de se débarrasser de.
choisir un framework web est une décision difficile, et j'éviterais de choisir une solution de pile complète juste pour exposer une api REST.
maintenant, si vous avez vraiment besoin/envie D'utiliser Django, alors Piston est un cadre de repos agréable pour les applications django.
cela étant dit, CherryPy semble vraiment agréable aussi, mais semble plus RPC que le repos.
en Regardant les échantillons (je ne l'ai jamais utilisé), probablement. web.py est le meilleur et le plus propre si vous avez seulement besoin de repos.
Voici une discussion dans CherryPy docs sur le repos: http://docs.cherrypy.org/dev/progguide/REST.html
en particulier, il mentionne un dispatcher CherryPy intégré appelé MethodDispatcher, qui invoque des méthodes basées sur leurs identificateurs HTTP-verb (GET, POST, etc...).
En 2010, les Pylônes et repoze.les communautés bfg "ont uni leurs forces" pour créer Pyramid , un cadre web basé principalement sur repoze.bfg. Il conserve les philosophies de ses cadres parents, et peut être utilisé pour RESTful services . Il vaut la peine de regarder.
Piston est un cadre très flexible pour wirting APIs RESTful pour les applications Django.
semble que toutes sortes de cadres web python peuvent implémenter des interfaces RESTful maintenant.
pour Django, outre le tastypie et le piston, django-rest-framework est prometteur et mérite d'être mentionné. J'ai déjà migré un de mes projets sur elle en douceur.
Django REST framework est un cadre de repos léger pour Django, qui vise à rendre facile de construire bien connecté, Auto-description RESTful Web APIs.
Rapide exemple:
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<pk>[^/]+)/$', InstanceModelView.as_view(resource=MyResource)),
)
prendre l'exemple du site officiel, tous les codes ci-dessus fournissent api, document auto-expliqué(comme soap basé webservice) et même bac à sable pour tester un peu. Très pratique.
web2py inclut le support pour facilement bâtiment API RESTful, décrit ici et ici (vidéo). En particulier, regardez parse_as_rest , qui vous permet de définir des modèles D'URL qui font correspondre les requêtes args à des requêtes de base de données; et smart_query , ce qui vous permet de passer des requêtes de langage naturel arbitraires dans L'URL.
I vous utilisez Django alors vous pouvez considérer django-tastypie comme une alternative à django-piston . Il est plus facile d'accorder aux sources de données non-ORM que piston, et a grande documentation .
je recommande vivement TurboGears ou à la Bouteille:
TurboGears:
- moins verbeux que django
- plus flexible, moins orienté HTML
- mais: moins célèbre
bouteille:
- très rapide
- très facile à apprendre
- mais: minimaliste et pas mature
nous travaillons sur un cadre pour les services de repos strict, consultez http://prestans.googlecode.com
Its en début D'Alpha en ce moment, nous testons contre mod_wsgi et L'AppEngine de Google.
cherche testeurs et feedback. Grâce.