python - tutorial - Marco para la implementación del servicio web REST en Django

run django rest server

Question

Estoy buscando implementar una interfaz RESTful para una aplicación Django. Es principalmente una aplicación de servicio de datos: la interfaz será (en este momento) de solo lectura.

La pregunta es qué conjuntos de herramientas / marcos de Django tienen más sentido para esta tarea.

Veo Django-rest y Django-piston. También existe la opción de rodar la mía.

La pregunta fue hecha aquí, pero hace dos años. Me gustaría saber cuál es el estado actual del juego.

En esta pregunta , alrededor del año 2008, la gran mayoría de los votos consistió en no usar ningún marco en absoluto; basta con crear vistas de Django que respondan con, por ejemplo, JSON. (La pregunta también fue abordada, crica 2008, aquí ).

En el panorama actual, ¿qué tiene más sentido?

Answer 1

NOTA: Desde que se escribió esta publicación, django-piston ya no se mantiene activamente. Como otros han mencionado, mira en tastypie o django-rest-framework .

De hecho, puedes lanzar el tuyo, pero hay un montón de repeticiones involucradas.

django-piston es un micro-marco excepcionalmente fácil de usar y extensible. Además de simular todas las vistas necesarias y los patrones de URL, es compatible directamente con los modelos de mapeo a una interfaz REST, lo cual es bueno si tiene un caso de uso simple. Sugeriría investigarlo.

Answer 2

Una forma es tirar la suya o usar django-piston, que es excelente. Pero el problema que tengo con pistón es que está hecho para ser adjuntado a un proyecto django existente para agregar una API. No está hecho para construir una API orientada a recursos con soporte para formatos que incluyen HTML.

La forma en que veo el caso de uso para Piston es que tienes un sitio web completo que sirve contenido html, pero luego adjuntas una API a la url / api / *. Luego vas y le agregas Piston. Con este caso de uso, Piston es genial, no es necesario reescribir el código existente y obtienes lo que necesites. Puede ser que Piston funcione bien sin separar la API de la parte del sitio orientada al usuario, pero no lo he intentado.

Es más fácil tratar de explicar esto con algunos ejemplos:

Bitbucket

• URL y contenido del usuario: https://bitbucket.org/jespern
• URL y contenido: https://api.bitbucket.org/1.0/users/jespern/

Github

• URL y contenido dirigidos al usuario: https://github.com/jgorset
• URL y contenido de la API: https://github.com/jgorset.json

Bitbucket está hecho con Django y django-piston para la API, mientras que Github está hecho con Ruby On Rails que ha incorporado soporte para recursos con diferentes formatos. No estoy diciendo que debas cambiar a RoR, porque todos amamos a Django, y no estoy diciendo que no puedas hacer esto con django, pero sería tedioso hacerlo tú mismo en cada vista.

Entonces, un compañero de trabajo y yo decidimos que queríamos algo de la "magia" de RoR en Django, pero no queríamos que fuera mágico, sino que nos facilitaba la vida sin abstraer todo. Así que jgorset escribió Respite, que es un pequeño framework de Django para hacer API "RESTful" de la misma manera que RoR, pero en Django. Todavía está en desarrollo temprano, pero lo usamos a diario en nuestros proyectos de trabajo y es altamente personalizable, al igual que Django. Intenta simplificar la creación de páginas web orientadas a recursos y estructurar su código sin interferir en su camino.

Así que, naturalmente, mi recomendación sería mirar y probar Respite: https://github.com/jgorset/django-respite/

Answer 3

Y dado que esta pregunta todavía tiene una calificación bastante alta en mis búsquedas en Google, agregaré esta alternativa a la mezcla: http://django-rest-framework.org/

Mi impresión inicial es que hace un muy buen trabajo encarnando los principios de diseño RESTful API descritos aquí: http://readthedocs.org/docs/restful-api-design/en/latest/

Answer 4

Usando django-rest-interface

Sigue siendo verdad.

Es bastante trivial rodar el tuyo. Cada URI de REST se asigna a una función de vista. Cada método REST (GET, POST, PUT, DELETE) es una condición simple en la función de vista.

Hecho.

Answer 5

tastypie también es una opción, lo probé y me pareció indolora hasta ahora. Estoy jugando con una aplicación ficticia que expone una API a un cliente de backbone.js y no he tocado paredes de ladrillo con esta biblioteca. Este artículo me hizo probarlo.