python - start - rest framework django 2

Forma correcta de consumir datos de la API RESTFUL en django

Question

Intento aprender django, por lo tanto, aunque tengo una solución actual, no estoy seguro si sigue las mejores prácticas en django. Me gustaría mostrar información de una API web en mi sitio web. Digamos que la URL de la aplicación es la siguiente:

http://api.example.com/books?author=edwards&year=2009

Thsis devolvería una lista de libros escritos por Edwards en el año 2009. Devolvió en el siguiente formato:

{''results'':
             [
                {
                   ''title'':''Book 1'',
                   ''Author'':''Edwards Man'',
                   ''Year'':2009
                },
                {
                   ''title'':''Book 2'',
                   ''Author'':''Edwards Man'',
                   ''Year'':2009}
           ]
}

Actualmente estoy consumiendo la API en mi archivo de vistas de la siguiente manera:

class BooksPage(generic.TemplateView):
    def get(self,request):
        r = requests.get(''http://api.example.com/books?author=edwards&year=2009'')
        books = r.json()
        books_list = {''books'':books[''results'']}
        return render(request,''books.html'',books_list)

Normalmente, tomamos datos de la base de datos en el archivo models.py, pero no estoy seguro si debería obtener estos datos API en models.py o views.py. Si debería estar en models.py, ¿alguien puede dar un ejemplo de cómo hacer esto? Escribí el ejemplo anterior específicamente para stackoverflow, por lo que cualquier error es simplemente el resultado de escribirlo aquí.

Answer 1

Bueno, hay varias cosas a tener en cuenta. En primer lugar, en este caso, sus datos no cambian con tanta frecuencia. Por lo tanto, es una buena práctica guardar en caché este tipo de respuestas. Hay muchas herramientas de almacenamiento en caché, pero redis es una opción popular. Alternativamente, puede elegir una base de datos NoSQL adicional solo para el almacenamiento en caché.

En segundo lugar, ¿cuál es el propósito de mostrar esta información? ¿Esperas que tus usuarios interactúen con libros o autores, etc.? Si se trata solo de información, no hay necesidad de formularios y modelos. De lo contrario, debe proporcionar vistas, formularios y modelos adecuados para libros y autores, etc.

Y teniendo en cuenta el lugar al que debe llamar una solicitud API, diría que depende en gran medida de la segunda pregunta. Las opciones son:

• views.py solo para mostrar datos.
• forms.py o still views.py para la ineractividad.

Answer 2

Me gusta el enfoque de poner ese tipo de lógica en una capa de servicio separada (services.py); los datos que está procesando no son un "modelo" en el sentido Django ORM, y es más que una simple lógica de "vista". Una encapsulación limpia garantiza que puede hacer cosas como controlar la interfaz para el servicio de respaldo (es decir, hacer que se vea como una API de Python vs. URL con parámetros), agregar mejoras como el almacenamiento en caché, como se menciona @sobolevn, probar la API de forma aislada, etc.

Así que sugeriría un simple services.py , que se ve así:

def get_books(year, author):
    url = ''http://api.example.com/books'' 
    params = {''year'': year, ''author'': author}
    r = requests.get(url, params=params)
    books = r.json()
    books_list = {''books'':books[''results'']}
    return books_list

Observe cómo se pasan los parámetros (utilizando una capacidad del paquete de requests ).

Luego en views.py :

import services
class BooksPage(generic.TemplateView):
    def get(self,request):
        books_list = services.get_books(''2009'', ''edwards'')
        return render(request,''books.html'',books_list)

Ver también:

• Separación de lógica de negocios y acceso a datos en django

Answer 3

Use el serializador en lugar de .json, ya que le da flexibilidad para devolverlo en una variedad de formatos. Al usar rest-api, se prefiere el uso del serializador proporcionado.

También mantenga la gestión de datos y obtenga las solicitudes de datos en view.py. Los formularios se utilizan para plantillas, no como la lógica comercial.