[PYTHON] Tornado - Erstellen wir eine Web-API, die JSON problemlos mit JSON zurückgibt
Auf dem vorderen Mund
tornado ist ein leichtes Web Framework und eine asynchrone Kommunikationsbibliothek. Es scheint seinen wahren Wert zu zeigen, wenn eine Kommunikationsmethode verwendet wird, die eine Verbindung über einen langen Zeitraum aufrechterhält, wie z. B. WebSocket und lange Abfragen. Dieses Mal wollte ich kein großes Web Framework wie "Django" für eine Serverimplementierung einer kleinen App verwenden, die eine JSON-formatierte Antwort zurückgibt, also habe ich "Tornado" ausprobiert.
Sie können auch "JSONEncorder" verwenden, um die Antwort zurückzugeben. Wenn Sie jedoch Tornado-JSON verwenden, lautet das Antwortformat JSend Es kann von JSON Schema angegeben oder validiert werden. Es kann auch dokumentiert werden, was nützlich erscheint, wenn Sie es in JSON über HTTP implementieren möchten.
Umgebung
Web Server: nginx Language: Python 2.7.10 OS: CentOS release 6.7 (Final)
Versichern
Installieren Sie zuerst tornado und Tornado-JSON mit pip.
pip install tornado
pip install Tornado-JSON
Ich konnte es ohne Probleme installieren.
Demos Teil 1 Hellowold
Nachdem die Installation abgeschlossen ist, klonen Sie Tornado-JSON von GitHub und probieren Sie die Demo aus.
cd Tornado-JSON/demos/helloworld
python helloworld.py
Wenn Sie die oben genannten Schritte ausführen, wird die Tornado-Anwendung gestartet. Sie können die der API-URL zugeordnete Klasse wie unten gezeigt sehen.
Lassen Sie uns tatsächlich eine Anfrage stellen. Sie können es über einen Browser verwenden, aber dieses Mal werde ich httpie verwenden, um es vom Terminal aus zu überprüfen. Probieren Sie die im Terminal angezeigten APIs von oben nach unten aus.
/api/helloworld/?
$ http GET <path/to/host>/api/helloworld/
HTTP/1.1 200 OK
Connection: keep-alive
Content-Length: 45
Content-Type: application/json; charset=UTF-8
Date: Thu, 21 Jan 2016 20:22:38 GMT
Etag: "2e708f71c76a9c77119c54d91746619abbbb28fc"
Server: nginx/1.0.15
Vary: Accept-Encoding
{
"data": "Hello world!",
"status": "success"
}
Scheint das einfachste Beispiel zu sein.
/api/freewilled/?
$ http GET <path/to/host>/api/freewilled/
HTTP/1.1 200 OK
Connection: keep-alive
Content-Length: 76
Content-Type: application/json; charset=UTF-8
Date: Thu, 21 Jan 2016 20:27:55 GMT
Etag: "81d9135b038a336645a03c17f8c1f58bf890a010"
Server: nginx/1.0.15
Vary: Accept-Encoding
{
"data": "I don't need no stinkin' schema validation.",
"status": "success"
}
Dies ist etwas verwirrend, aber es scheint ein Beispiel ohne Validierung zu sein.
/api/postit/?
#In httpie besteht der numerische Typ darin, den rohen JSON zu senden=nicht:=Beachten Sie, dass es in angegeben ist.=Wenn Sie mit angeben, wird der numerische Wert zu einem Zeichenfolgentyp, und bei der Validierung tritt ein Fehler auf.
$ http POST <path/to/host>/api/postit/ title='post it' body='hello world' index:=0
HTTP/1.1 200 OK
Connection: keep-alive
Content-Length: 65
Content-Type: application/json; charset=UTF-8
Date: Thu, 21 Jan 2016 20:30:53 GMT
Server: nginx/1.0.15
Vary: Accept-Encoding
{
"data": {
"message": "post it was posted."
},
"status": "success"
}
Dies ist ein Beispiel für die POST-Methode, nicht für die GET-Methode. Da die API Titel, Text und Index als Parameter enthält, schlägt die Validierung fehl, wenn diese nicht angegeben werden. Als es fehlschlug, wurde es wie folgt.
$ http POST <path/to/host>/api/postit/ title='post it' body='hello world' index=0
HTTP/1.1 400 Bad Request
Connection: keep-alive
Content-Length: 179
Content-Type: application/json; charset=UTF-8
Date: Fri, 22 Jan 2016 16:02:19 GMT
Server: nginx/1.0.15
Vary: Accept-Encoding
{
"data": "u'0' is not of type 'number'\n\nFailed validating 'type' in schema['properties']['index']:\n {'type': 'number'}\n\nOn instance['index']:\n u'0'",
"status": "fail"
}
/api/greeting/(?P<fname>[a-zA-Z0-9_\-]+)/(?P<lname>[a-zA-Z0-9_\-]+)/?$
$ http GET <path/to/host>/api/greeting/John/Smith
HTTP/1.1 200 OK
Connection: keep-alive
Content-Length: 55
Content-Type: application/json; charset=UTF-8
Date: Thu, 21 Jan 2016 20:45:36 GMT
Etag: "8e58c6953fdb166e2912eca36881f55885f20073"
Server: nginx/1.0.15
Vary: Accept-Encoding
{
"data": "Greetings, John Smith!",
"status": "success"
}
Dies ist ein Beispiel für eine URL, die reguläre Ausdrücke verwendet. John und Smith werden mit den Schlüsseln fname bzw. lname erfasst und können in Python-Programmen referenziert werden.
/api/asynchelloworld/(?P
$ http GET <path/to/host>/api/asynchelloworld/Smith
HTTP/1.1 200 OK
Connection: keep-alive
Content-Length: 78
Content-Type: application/json; charset=UTF-8
Date: Thu, 21 Jan 2016 20:48:19 GMT
Etag: "4f1db48667213b44adbacc2a85599bca86c72f19"
Server: nginx/1.0.15
Vary: Accept-Encoding
{
"data": "Hello (asynchronous) world! My name is Smith.",
"status": "success"
}
Hallo, asynchrone Welt. Es sieht also wie ein Beispiel aus, das eine asynchrone Bibliothek verwendet.
Die oben genannten API-Implementierungen stammen von GitHub demos / helloworld / helloworld.py und demos / helloworld / helloworld /api.py. Es scheint, dass die gewünschte Verarbeitung unter Bezugnahme auf diese implementiert werden kann.
Demos Teil 2 rest_api
Dies ist eine Demo mit URLconf.
Wenn ich mir die Implementierung von helloworld ansehe, stelle ich fest, dass ich URLconf (urlpatterns in Django) nicht finden kann.
Was bedeutet das?
Tatsächlich hat "APIHandler" Klassenvariablen vom Listentyp mit den Namen "urls", "url_names". Wenn Sie dies überschreiben, werden URLs automatisch generiert. Die generierten URLs werden mit der Funktion tornado_json.routes.get_routes abgerufen. Dies scheint die URLconf-Methode von Tornado-JSON zu sein.
Weitere Informationen finden Sie unter demos / rest_api / cars / api / \ _ \ _ init \ _ \ _. Py. Es ist in init.py # L20) beschrieben.
Eigentlich etwas machen und veröffentlichen
Es gibt keine solche Sache. (Ich bin erschöpft. Vielleicht mache ich es später, wenn ich Lust dazu habe?
Eindrücke habe ich versucht
Es mag verschiedene Fallen geben, aber ich bin froh, dass es leicht ist. Asynchrone Verarbeitung und nicht blockierende E / A, die am attraktivsten zu sein scheinen, wurden nicht im Detail untersucht, aber es ist interessant zu sehen, was insbesondere in Kombination mit WebSocket passiert.
In Bezug auf "Tornado-JSON" ist es attraktiv, wenn man bedenkt, dass sich die Anforderungen für die WEB-Entwicklung heutzutage auf "JSON über HTTP" verlagern. Ich bin jedoch ein wenig besorgt, dass die Entwicklung nicht sehr aktiv ist und es nur sehr wenige Mitwirkende gibt, 4 Personen. Andererseits ist "Tornado" relativ aktiv, daher fühle ich mich ein wenig erleichtert.
Referenz
Was "Tornado" betrifft, so scheint es, dass um 2012 ein (wahrscheinlich das einzige) Buch veröffentlicht wurde. https://github.com/Introduction-to-Tornado/Introduction-to-Tornado
Recommended Posts