¡Descarga API REST con Python. y más Ejercicios en PDF de Programación Informática solo en Docsity!
Instalando un entorno virtual
Un entorno virtual nos permite aislar librerías y versiones de python si es que así lo deseamos, por esto es que es tan común la práctica de crear entornos virtuales al desarrollar aplicaciones con python, ya que fácilmente evitamos confusiones y conflictos entre las diferentes versiones de librerías y entre las diferentes versiones del mismo python. Para instalar un entorno virtual haremos uso de pip (herramienta ya incluida en python. Si el sistema no reconoce pip, instalarlo).
- Crear un directorio para albergar nuestro proyecto (back-end). Desde la terminal (cmd en windows), creamos un directorio en la ubicación deseada. $ mkdir plantas
- Posicionarse en el directorio recién creado. $ cd plantas
- Instalar el entorno virtual con el comando pip : $ pip install virtualenv (puede que ya lo tengas instalado previemnete)
- Launch it: $ virtualenv venv (venv es la carpeta en donde serán alojadas todas las dependencias y archivos que serán instalados en el entorno virtual, realmente se le puede llamar como uno quiera, aunque una recomendación es que el nombre haga alusión a que se trata de la carpeta del entorno virtual). La razón por la cual encapsulamos en una carpeta todos los archivos del entorno virtual, es porque no queremos subir posteriormente en producción alguno de estos archivos a un repositorio remoto, cuando implementamos nuestro proyecto en un servidor. Cuando subamos nuestro proyecto a un servidor y lo pongamos en producción, necesitaremos un nuevo entorno virtual en donde instalaremos todos los paquetes que utilizamos en la fase de desarrollo. Los nombres y versiones de los paquetes los dejaremos registrados en un archivo llamado requirements.txt.
- Activar el entorno virtual :
$ source venv/bin/activate (para windows utilizar venv\Scripts\activate) (venv) MacBook-Air-de-Luis:plantas user$ (algo como esto deberá aparecer en la terminal indicando que se esta dentro del entorno virtual)
- Instalar django: $ pip install django==3.1 (Para este caso se utiliza la versión 3.1, si se quiere utilizar una versión mas reciente de django, asegure de usarla con la versión más reciente de python). Si quiere instalar la versión más reciente de Django, usar el comando “pip install django”.
- Listar los paquetes actualmente instalados en el entorno virtual: $ pip freeze
- Escribir en un archivo llamado requirements.txt los nombres de todos los paquetes instalados en el entorno virtual: $ pip freeze > requirements.txt
$ pip install djangorestframework
- Escribir en el archivo llamado requirements.txt los nombres de todos los paquetes instalados en el entorno virtual hasta el momento: $ pip freeze > requirements.txt 10.Agregar la API Django REST (rest_framework) al listado INSTALLED_APPS en el archivo settings.py:
Práctica 2
Construyendo el back-end de
la aplicación web plantas
Diseñando la aplicación de Django
Un proyecto de Django esta formado por multiples apps, unas de las cuales son creadas automáticamente al crear un proyecto de Django y otras tantas pueden ser creadas por el desarrollador, estas apps son secciones de código que se encargan de desarrollar una tarea en especifico, el uso de apps permite modularizar un proyecto de Django facilitando el mantenimiento, actualización y escalamiento del mismo.
- Crear una nueva app interna de Django para colectar, almacenar y manipular datos sobre las plantas, a la cual llamaremos stores: $ python manage.py startapp stores (Previamente asegurarse de que el servidor interno de Django no este corriendo y de estar dentro de la carpeta que contiene el archivo manage.py)
- Agregar la nueva aplicación interna stores al listado de INSTALLED_APPS en el archivo settings.py. La idea básica de las apps internas en Django es dividir lo más que se pueda el proyecto, de tal manera que cada app interna tiene sus propios modelos y vistas. De esta manera la app interna stores recién creada, contendrá los modelos relacionados a una planta. Es una buena práctica no incluir más de 5 modelos dentro de un app interna en Django, esto con el objetivo de no sobrecargarla.
- Crear el despachador URL para la app interna stores. Dentro de la app interna stores, crear un archivo llamado urls.py, en este archivo es donde se definirán los patrones URL locales para las operaciones básicas que se pueden realizar sobre los datos de los modelos
$ cd plantaproject $ python manage.py makemigrations $ python manage.py migrate
- Registrar nuestro modelo en el archivo admin.py para tener acceso a la base de datos. Al agregar un modelo al archivo admin.py, nos permite agregar y actualizar información en la base de datos utilizando un template de administrador. Para registrar el modelo Planta, abrir el archivo admin.py de la app stores y en la parte superior importar el modelo Planta from models: “””El punto antes de models hace referencia a la carpeta donde se encuentra el archivo que se esta editando””” Si se desea importar el modelo desde otro lugar, por ejemplo desde otra app o desde un archivo fuera de la app nativa Stores, se debe proveer el path completo: from stores.models import Planta
- Registrar el modelo Planta. El comando admin.site.register creará un formulario para el modelo, en la interfaz de administrador.
- Lanzar el servidor interno para visualizar el formulario que nos permite realizar operaciones básicas a nivel de base de datos sobre nuestro modelo Planta: $ python manage.py runserver 10.Abrir el navegador e ir a la ruta: http://localhost:8000/admin
Ahora aparece la app Stores y dentro de ella, el modelo Planta.
- Agregar algunos registros al modelo: Si visualizamos los registros dentro del modelo plantas, nos aparecerán como objetos Planta, esto se debe a que cada registro del modelo es regresado como un objeto tipo Planta.
- Visualizar los registros con el nombre y el tipo de la planta. Todos los objetos tienen un método llamado str(), el cual por default regresa el tipo el nombre de la clase a la cual pertenece el objeto. Para cambiar lo que regresa este método, tenemos que sobreescribirlo dentro de la clase correspondiente. Para lograr que el método str() regrese el nombre y el tipo de la planta, agregamos estas líneas de código dentro y al final de la clase Planta, en el archivo models.py de nuestra app Stores:
- Refrescar la página de administrador en el agente de usuario. Se debe de ver el nombre y el tipo de cada planta.
Esta vista será la encargada de mostrar al usuario un listado de todas las plantas con los atributos definidos en el serializer PlantaListSerializer. En este caso se muestran todas las plantas, ya que la consulta por medio del método all() así lo indica (queryset = Planta.objects.all()), sí se desea se puede realizar una consulta personalizada. La vista recién creada es una vista genérica que contiene los métodos CRUD (por eso importamos generics de rest_framework), aunque también se pueden crear vistas personalizadas. D. Diseñar URL’s para la app stores y asignarlas a nuestro despachador de URL’s. Para ello requerimos abrir el archivo urls.py de la carpeta stores y agregar el siguiente código: Las vistas pueden ser importadas de una en una o todas de una vez tal y como se muestra en el código anterior. Todos los patrones serán agregados en la lista urlpatterns. La función path() recibe 3 argumentos, el primero indica el patrón a seguir después del nombre del dominio, en este caso no hay patron, por lo tanto si se quiere invocar la vista PlantaListAPIView, solo bastara con escribir el nombre del dominio, el segundo argumento indica cual vista será invocada para este patrón y el tercer argumento name almacena una etiqueta que podrá ser utilizada después para referencias nuestra URL. La URL que acabamos de crear es una URL local para la app stores, para conectarla al desecahador de URL’s global urls.py contenido en la carpeta plantaproject, necesitamos importar la función include de django.urls y agregar a la lista urlpatterns un root path para el archivo urls.py de la app stores. Para esto, abrimos con un editor de códigos, el archivo urls.py contenido en la carpeta plantaproject y agregamos el siguiente código:
El path con el esquema vacío, podrá controlar una solicitud y redirigirla al archivo urls.py de la app stores. El proceso de diseñar URL’s se repite, así cada vez que se agregue una nueva vista a nuestro archivo views.py, necesitaremos codificar la vista y agregar un patrón URL al archivo local urls.py de la app. Y cada vez que se agrega una app a un proyecto de Django, es necesario conectar una única vez el despachador URL global con el archivo urls.py local de la app.
- Guardar todos los cambios y reiniciar el servidor de desarrollo, asegurase de estar en la carpeta que contiene el archivo manage.py: $ python manage.py runserver
- Escribir en la barra de direcciones del agente de usuario lo siguiente: http://localhost:8000/ Como podemos ver, se muestra un listado de plantas con atributos básicos y en un formato json, esta información puede ser solicitada vía GET por nuestra aplicación móvil y/o web y será enviada por nuestro servidor.
Podemos observar que en vez de heredar de ListAPIView, heredamos de RetrieveAPIView, la cual nos permite consultar un único elemento en ves de una lista completa, y para un identificador único, requerimos agregar el atributo lookup_field (nombre de atributo genérico incluido en generics del framework REST de Django) para especificar el campo por medio del cual consultaremos nuestro modelo. D. Agregar un path para la vista PlantaRetieveAPIView en nuestra lista urlpatterns. Para ello requerimos abrir el archivo urls.py de la carpeta stores y agregar el siguiente path: “<int:id>/” es un patrón que indica un entero y el nombre de un campo, así cuando queremos obtener un registro en particular, necesitamos pasar después de la URL un valor entero que corresponda al id del registro que se quiere consultar.
- Guardar todos los cambios y reiniciar el servidor de desarrollo, asegurase de estar en la carpeta que contiene el archivo manage.py: $ python manage.py runserver
- Escribir en la barra de direcciones del agente de usuario lo siguiente: http://localhost:8000/2/ Como a la URL le agregamos el número entero 2, entonces se muestran en un formato json todos los atributos de la segunda planta que insertamos en nuestra tabla
plantas. Al igual que en List View, esta información puede ser solicitada vía GET por nuestra aplicación móvil y/o web y será enviada por nuestro servidor.
Diseño de Create View (crear una planta)
Para diseñar Create View se siguen los mismos pasos anteriores que para Details View o List view. Y recordando que un serializer puede ser reutilizado en diferentes vistas, y como para nuestro Create View requerimos todos los campos para poder crear un nuevo registro en la base de datos, entonces reutilizaremos el serializer PlantaDetailSerializer. La principal diferencia entre Retrieve views y Create views radica en los métodos HTTP utilizados por una y otra, por un lado Retrieve views utiliza el método GET y Create views utiliza el método POST.
- Definir un Create View en views.py. Abrir con algún editor de texto, el archivo views.py contenido en el directorio stores y agregar la siguiente clase después de la clase PlantaRetrieveAPIView: Podemos observar que en vez de heredar de ListAPIView o de RetrieveAPIView, heredamos de CreateAPIView, la cual nos permite crear un elemento.
- Agregar un path para la vista PlantaCreateAPIView en nuestra lista urlpatterns. Para ello requerimos abrir el archivo urls.py de la carpeta stores y agregar el siguiente path: Considerando que se trata de un nuevo registro, por lo tanto no necesitamos pasarle un valor para el campo id al final de la URL. Para crear un patrón único que invoque la Create View, la URL puede contener una palabra al final, esta palabra puede ser la que uno quiera, aunque es una buena práctica el que sea descriptiva, por lo tanto en esta ocasión le agregamos la palabra create.
- Probar nuestra vista. Llenar el formulario y seleccionar una imagen, posteriormente dar click en el botón POST. Podemos observar que nuestro registro se ha creado y podemos verlo en nuestra List View y/o Detail View si es que así lo deseamos.
Diseño de Update View (actualizar una planta)
Para diseñar Update View se siguen los mismos pasos anteriores que para Créate View. Y recordando que un serializer puede ser reutilizado en diferentes vistas, y como para nuestro Update View requerimos todos los campos para poder crear un nuevo registro en la base de datos, entonces reutilizaremos el serializer PlantaDetailSerializer. La principal diferencia entre Créate views y Update views radica en los métodos HTTP utilizados por una y otra, por un lado Créate views utiliza el método POST y Update views utiliza los métodos GET, PUT y PATCH. De esta manera podemos observar que en una API REST, el método POST es utilizado cuando se quiere crear un nuevo elemento, y el método PUT es utilizado cuando se quiere modificar un elemento ya existente.
- Definir un Retrieve Update View en views.py. Abrir con algún editor de texto, el archivo views.py contenido en el directorio stores y agregar la siguiente clase después de la clase PlantaCreateAPIView: Podemos observar que en vez
de heredar de CreateAPIView, heredamos de RetrieveUpdateAPIView, la cual primero muestra el elemento, así pueden ser visualizados los detalles del elemento para posteriormente actualizarlos.
- Agregar un path para la vista PlantaRetrieveUpdateAPIView en nuestra lista urlpatterns. Para ello requerimos abrir el archivo urls.py de la carpeta stores y agregar el siguiente path: Considerando que se trata de actualizar un registro existente, necesitamos pasarle un valor para el campo id al final de la URL. Para crear un patrón único que invoque la Retrieve Update View, la URL puede contener una palabra al final, esta palabra puede ser la que uno quiera, aunque es una buena práctica el que sea descriptiva, por lo tanto en esta ocasión le agregamos la palabra update y después de ella le agregaremos un entero que indica el id del elemento que se quiere actualizar.
- Guardar todos los cambios y reiniciar el servidor de desarrollo, asegurase de estar en la carpeta que contiene el archivo manage.py: $ python manage.py runserver
- Escribir en la barra de direcciones del agente de usuario lo siguiente: http://localhost:8000/update/2/
Diseño de Delete View (eliminar una planta)
Para diseñar Delete View se siguen los mismos pasos anteriores que para Update View. En este caso no se requiere utilizar un atributo serializer en la clase, basta con incluir los atributos lookup_id y queryset. La principal diferencia entre Delete views y las demás views radica en los métodos HTTP utilizados por unas y otras, por un lado Delete views utilizan el método DELETE y las demás views utilizan los métodos GET, PUT y PATCH, CREATE y/o UPDATE según sea el caso. De esta manera podemos observar que en una API REST, el método DELETE es utilizado cuando se quiere eliminar un elemento existente.
- Definir un Destroy View en views.py. Abrir con algún editor de texto, el archivo views.py contenido en el directorio stores y agregar la siguiente clase después de la clase PlantaRetrieveUpdateAPIView: Podemos observar que en vez de heredar de RetrieveUpdateAPIView, heredamos de DestroyAPIView, la cual permite enviar solamente una solicitud DELETE.
- Agregar un path para la vista PlantaDestroyAPIView en nuestra lista urlpatterns. Para ello requerimos abrir el archivo urls.py de la carpeta stores y agregar el siguiente path: Considerando que se trata de eliminar un registro existente, necesitamos pasarle un valor para el campo id al final de la URL. Para crear un patrón único que invoque la Destroy View, la URL puede contener una palabra al final, esta palabra puede ser la que uno quiera, aunque es una buena práctica el que sea descriptiva, por lo tanto en esta ocasión le agregamos la palabra delete y después de ella le agregaremos un entero que indica el id del elemento que se quiere eliminar.
- Guardar todos los cambios y reiniciar el servidor de desarrollo, asegurase de estar en la carpeta que contiene el archivo manage.py:
$ python manage.py runserver
- Escribir en la barra de direcciones del agente de usuario lo siguiente: http://localhost:8000/delete/4/ Como podemos visualizar, nos aparece un warning diciendo que el método GET no es permitido, ya que nuestra PlantaDestroyAPIView acepta únicamente el método DELETE. En la parte superior derecha aparece un botón en color rojo con la palabra DELETE, el cual es el único medio en esta página HTML para enviar la solicitud DELETE, una vez que se da click sobre el botón rojo, nos aparecerá un mensaje de confirmación preguntándonos si realmente queremos eliminar el registro, esto es una implementación de Django para proteger la integridad de los datos en una aplicación y cerciorarse de que no se elimine información esencial. Si no necesitas más el registro con id 4, puedes proceder y PlantasDestroyAPIView debe borrar el registro de la base de datos, lo cual puedes corroborar consultando nuestra List View o Detail View en http://localhost:8000/.
