Czy jest gdzieś lista rekomendacji różnych frameworków REST opartych na Pythonie do wykorzystania na serwerze do pisania własnych interfejsów API RESTful? Najlepiej z zaletami i wadami.
Tutaj możesz dodać rekomendacje. :)
Odpowiedzi:
Podczas projektowania interfejsu API RESTful należy zachować ostrożność, jeśli chodzi o połączenie GET i POST, tak jakby były one tym samym. To proste, aby ten błąd z Django 's poglądów opartych funkcyjnych i CherryPy jest domyślnym dyspozytora, choć obie ramy teraz dostarczyć sposób wokół tego problemu ( poglądów opartych na klasach i MethodDispatcher , odpowiednio).
Czasowniki HTTP są bardzo ważne w REST i jeśli nie będziesz bardzo ostrożny, skończysz w anty-wzorcu REST .
Niektóre frameworki, które dobrze to robią , to web.py , Flask i Bottle . W połączeniu z biblioteką mimerender (pełne ujawnienie: napisałem to), pozwalają ci pisać fajne usługi internetowe RESTful:
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()Logika usługi jest implementowana tylko raz, a poprawny wybór reprezentacji (nagłówek Akceptuj) + wysłanie do odpowiedniej funkcji renderowania (lub szablonu) odbywa się w uporządkowany, przejrzysty sposób.
$ 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!Aktualizacja (kwiecień 2012 r.) : Dodano informacje o widokach klasowych Django, metodach MethodDispatcher CherryPy oraz platformach Flask i Bottle. Żadne z nich nie istniało, kiedy zadano pytanie.
Zaskoczony nikt nie wspomniał o kolbie .
from flask import Flask
app = Flask(__name__)
@app.route("/")
def hello():
return "Hello World!"
if __name__ == "__main__":
app.run()Używamy Django do usług sieciowych RESTful.
Zauważ, że - po wyjęciu z pudełka - Django nie miał wystarczająco szczegółowego uwierzytelnienia na nasze potrzeby. Użyliśmy interfejsu Django-REST , który bardzo nam pomógł. [Od tego czasu stworzyliśmy własne, ponieważ zrobiliśmy tyle rozszerzeń, że stał się koszmarem konserwacji.]
Mamy dwa rodzaje adresów URL: adresy URL „html”, które implementują strony HTML zorientowane na człowieka, oraz adresy URL „json”, które implementują przetwarzanie zorientowane na usługi sieciowe. Nasze funkcje widoku często wyglądają tak.
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 responseChodzi o to, że użyteczna funkcjonalność jest uwzględniona w dwóch prezentacjach. Prezentacja JSON jest zwykle tylko jednym obiektem, który został zamówiony. Prezentacja HTML często zawiera wszelkiego rodzaju pomoce nawigacyjne i inne wskazówki kontekstowe, które pomagają ludziom w produktywności.
Wszystkie jsonViewfunkcje są bardzo podobne, co może być nieco denerwujące. Ale to jest Python, więc włącz ich do klasy na żądanie lub napisz dekoratorów, jeśli to pomoże.
y = someUsefulThing(...)jest to „Okropne powtórzenie”, wówczas wszystkie odniesienia do wszystkich funkcji i metod są „okropne”. Nie rozumiem, jak unikać odwoływania się do funkcji więcej niż raz.
someUsefulThing(request, object_id)jest z wyrażeniem pobierania danych. Teraz masz dwie kopie tego samego wyrażenia w różnych punktach swojego programu. W zaakceptowanej odpowiedzi wyrażenie danych jest zapisywane jeden raz. Zastąp swoje someUsefulThingpołączenie długim ciągiem, polub paginate(request, Post.objects.filter(deleted=False, owner=request.user).order_by('comment_count'))i spójrz na kod. Mam nadzieję, że to zilustruje mój punkt widzenia.
Zobacz wiki Python Web Frameworks .
Prawdopodobnie nie potrzebujesz ram pełnego stosu , ale pozostała lista jest wciąż dość długa.
Naprawdę lubię CherryPy . Oto przykład spokojnej usługi internetowej:
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())Podkreśla to, co naprawdę lubię w CherryPy; jest to całkowicie działający przykład, który jest bardzo zrozumiały nawet dla kogoś, kto nie zna frameworka. Jeśli uruchomisz ten kod, możesz natychmiast zobaczyć wyniki w przeglądarce internetowej; np. odwiedzając http: // localhost: 8080 / celc_to_fahr? stopni = 50 wyświetli się 122.0w przeglądarce internetowej.
Nie widzę żadnego powodu, aby używać Django tylko do ujawnienia interfejsu API REST, istnieją lżejsze i bardziej elastyczne rozwiązania. Django przenosi na stół wiele innych rzeczy, które nie zawsze są potrzebne. Na pewno nie jest to konieczne, jeśli chcesz udostępnić tylko część kodu jako usługę REST.
Moje osobiste doświadczenie, fwiw, polega na tym, że kiedy będziesz mieć uniwersalną strukturę, zaczniesz używać jej ORM, wtyczek itp. Tylko dlatego, że jest to łatwe i w żadnym momencie nie będziesz zależny bardzo trudno się go pozbyć.
Wybór frameworka jest trudną decyzją i unikałbym wyboru rozwiązania pełnego stosu tylko po to, aby odsłonić interfejs API REST.
Teraz, jeśli naprawdę potrzebujesz / chcesz korzystać z Django, to Piston to przyjemny framework REST dla aplikacji django.
To powiedziawszy, CherryPy też wygląda naprawdę ładnie, ale wydaje się bardziej RPC niż REST.
Patrząc na próbki (nigdy go nie użyłem), prawdopodobnie web.py jest najlepszy i najczystszy, jeśli potrzebujesz tylko REST.
Oto dyskusja w dokumentach CherryPy na temat REST: http://docs.cherrypy.org/dev/progguide/REST.html
W szczególności wspomina o wbudowanym dyspozytorze CherryPy o nazwie MethodDispatcher, który wywołuje metody oparte na ich identyfikatorach czasowników HTTP (GET, POST itp.).
W 2010 r. Społeczności Pylons i repoze.bfg „połączyły siły”, aby stworzyć Pyramid , platformę internetową opartą w największym stopniu na repoze.bfg. Zachowuje filozofię swoich struktur nadrzędnych i może być używany do usług RESTful . Warto spojrzeć.
Tłok jest bardzo elastyczną strukturą do okablowania interfejsów API RESTful dla aplikacji Django.
Wygląda na to, że wszelkiego rodzaju frameworki sieci Python mogą teraz implementować interfejsy RESTful.
Dla Django, oprócz tastypie i tłoka, django-rest-framework jest obiecującym wartym wspomnienia. Płynnie migrowałem już jeden z moich projektów.
Struktura REST Django to lekka platforma REST dla Django, której celem jest ułatwienie tworzenia dobrze połączonych, samoopisujących interfejsów API RESTful Web.
Szybki przykład:
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)),
)Weźmy przykład z oficjalnej strony, wszystkie powyższe kody zapewniają interfejs API, własny objaśniający dokument (jak usługa internetowa na bazie mydła), a nawet piaskownicę, aby trochę przetestować. Bardzo wygoda.
web2py zawiera obsługę łatwego budowania RESTful API, opisanych tutaj i tutaj (wideo). W szczególności spójrz na parse_as_rest, co pozwala zdefiniować wzorce adresów URL, które mapują argumenty żądań na zapytania do bazy danych; i smart_query, który umożliwia przekazywanie dowolnych zapytań w języku naturalnym w adresie URL.
Jeśli używasz Django, możesz rozważyć django-tastypie jako alternatywę dla tłoka django . Łatwiej jest dostroić źródła danych spoza ORM niż tłok i ma świetną dokumentację .
Pracujemy nad ramą dla ścisłych usług REST, sprawdź http://prestans.googlecode.com
W tej chwili na początku Alpha, testujemy przeciwko mod_wsgi i Google AppEngine.
Poszukuję testerów i opinii. Dzięki.