Tornado - Créons une API Web qui renvoie facilement JSON avec JSON

Sur la bouche avant

tornado est un framework Web léger et une bibliothèque de communication asynchrone. Il semble montrer sa vraie valeur lors de l'adoption d'une méthode de communication qui maintient une connexion pendant une longue période, comme WebSocket et une longue interrogation. Cette fois, je ne voulais pas utiliser un grand framework Web comme Django pour une implémentation serveur d'une petite application qui renvoie une réponse au format JSON, alors j'ai essayé tornado.

Vous pouvez également utiliser JSONEncorder pour renvoyer la réponse, mais si vous utilisez Tornado-JSON, le format de réponse sera JSend Il peut être spécifié ou validé par JSON Schema. Il peut également être documenté, ce qui semble utile si vous souhaitez l'implémenter en JSON sur HTTP.

environnement

Web Server: nginx Language: Python 2.7.10 OS: CentOS release 6.7 (Final)

Assurer

Tout d'abord, installez tornado et Tornado-JSON avec pip.

pip install tornado

pip install Tornado-JSON

J'ai pu l'installer sans aucun problème.

démos partie 1 hellowold

Une fois l'installation terminée, clonez Tornado-JSON à partir de GitHub et essayez la démo.

cd Tornado-JSON/demos/helloworld
python helloworld.py

Faire ce qui précède lancera l'application tornade. Vous pouvez voir la classe associée à l'URL de l'API comme indiqué ci-dessous.

Faisons une demande. Vous pouvez l'utiliser depuis un navigateur, mais cette fois j'utiliserai httpie pour le vérifier depuis le terminal. Essayez les API affichées dans le terminal de haut en bas.

/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"
}

Semble être l'exemple le plus simple.

/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"
}

C'est un peu déroutant, mais cela semble être un exemple sans validation.

/api/postit/?

#Dans httpie, le type numérique est d'envoyer le json brut=ne pas:=Notez qu'il est spécifié dans.=Si vous spécifiez avec, la valeur numérique devient un type de chaîne de caractères et une erreur se produit lors de la validation.
$ 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"
}

Ceci est un exemple de méthode POST, pas de méthode GET. Puisque l'API a le titre, le corps et l'index comme paramètres, la validation échouera si ceux-ci ne sont pas spécifiés. Quand il a échoué, il est devenu comme suit.

$ 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"
}

Ceci est un exemple d'URL qui utilise des expressions régulières. John et Smith sont capturés avec les clés fname et lname, respectivement, et peuvent être référencés à partir de programmes Python.

/api/asynchelloworld/(?P[a-zA-Z0-9_\-]+)/?$

$ 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"
}

Bonjour, monde asynchrone. Cela ressemble donc à un exemple utilisant une bibliothèque asynchrone.

Les implémentations d'API ci-dessus proviennent de GitHub demos / helloworld / helloworld.py et demos / helloworld / helloworld /api.py. Il semble que le traitement souhaité peut être mis en œuvre en se référant à ceux-ci.

démos partie 2 rest_api

Ceci est une démo montrant URLconf.

Quand je regarde l'implémentation de helloworld, je remarque que je ne trouve pas URLconf (ʻurlpatternsdansDjango`). Qu'est-ce que ça veut dire?

En fait, ʻAPIHandler a des variables de classe de type liste nommées urls, url_names, et si vous remplacez cela, les URL seront générées automatiquement. Les URL générées sont obtenues avec la fonction tornado_json.routes.get_routes. Cela semble être la méthode URLconf de Tornado-JSON`.

Pour plus d'informations, voir [demos / rest_api / cars / api / \ _ \ _ init \ _ \ _. Py](https://github.com/hfaran/Tornado-JSON/blob/master/demos/rest_api/cars/api/ Il est décrit dans init.py # L20).

En fait, faites quelque chose et publiez

Il n'y a pas une telle chose. (Je suis épuisé ... Peut-être que je le ferai plus tard si j'en ai envie?

Impressions que j'ai essayées

Il peut y avoir différents pièges, mais je suis heureux qu'il soit léger. Le traitement asynchrone et les E / S non bloquantes, qui semblent être les plus attractifs, n'ont pas été étudiés en détail, mais il est intéressant de voir ce qui se passe surtout lorsqu'il est combiné avec WebSocket.

En ce qui concerne Tornado-JSON, il est intéressant étant donné que les exigences pour le développement WEB de nos jours sont en train de passer à JSON sur HTTP. Cependant, je suis un peu inquiet que le développement ne soit pas très actif et qu'il y ait très peu de contributeurs, 4 personnes. Par contre, «tornade» est relativement active, donc je me sens un peu soulagé.

référence

Quant à «tornado», il semble qu'un livre (probablement le seul) ait été publié vers 2012. https://github.com/Introduction-to-Tornado/Introduction-to-Tornado