Como desarrollador backend, busco proporcionar a los programadores frontend, una manera sencilla de obtener los datos que requieren las interfaces de usuario, concretamente, en el equipo mobile de Intelligenia al que pertenezco, estos datos servirán tanto para una app móvil, como para una interfaz web hecha en angular, por lo que implementando una API RESTful consistente, podríamos alimentar ambas, y además, proporcionar nuestra fuente de servicios para el consumo por parte de terceros.
La interfaz de programación de aplicaciones, abreviada como API del inglés: Application Programming Interface, es un conjunto de subrutinas, funciones y procedimientos que ofrece cierta biblioteca para ser utilizado por otro software como una capa de abstracción.
Buscando una definición sencilla, REST es cualquier interfaz entre sistemas que use HTTP para obtener datos o generar operaciones sobre esos datos en todos los formatos posibles, como XML y JSON. Es una alternativa en auge a otros protocolos estándar de intercambio de datos como SOAP, que disponen de una gran capacidad pero también mucha complejidad. A veces es preferible una solución más sencilla de manipulación de datos como REST.
Un servicio web RESTful contiene lo siguiente:
1. URI del recurso.
Una URI se estructura de la siguiente forma:
{protocolo}://{dominio}{:puerto(opcional)}/{ruta del recurso}?{parámetros}
{protocolo}://{dominio}{:puerto(opcional)}/{ruta del recurso}?{parámetros}
2. El tipo de la representación de dicho recurso.
Por ejemplo, podemos devolver en nuestra cabecera “Content-type: application/json”, por lo que el cliente sabrá que el contenido de la respuesta es una cadena en formato JSON, y podrá procesarla como prefiera. El tipo es arbitrario, siendo los más comunes JSON, XML y TXT.
3. Operaciones soportadas.
HTTP define varios tipos de operaciones o verbos, que pueden ser GET, PUT, POST, DELETE, PATCH, entre otros. Es importante saber para que están pensados cada verbo, de modo que sean utilizados correctamente por los clientes:
• GET: Se utiliza para consultar, leer y en definitiva acceder a un recurso
• POST: Envía datos para crear un recurso. Como en cualquier petición POST, los datos deben ir incluidos en el cuerpo de la petición.
• PUT: Utilizado para editar un recurso. Al igual que el POST, los datos deben ir en el cuerpo de la petición.
• DELETE: Es la opción para eliminar un recurso
• PATCH: Se utiliza para modificar parcialmente un recurso, aunque se utiliza en muy pocas ocasiones. Normalmente se utiliza simplemente PUT
El uso correcto de estos métodos es básico para considerar una API como REST. No se debería diseñar una API que realice modificaciones sobre un recurso mediante métodos GET, o que elimine elementos mediante un POST, sin embargo, existen numerosos casos de este tipo.
• GET: Se utiliza para consultar, leer y en definitiva acceder a un recurso
• POST: Envía datos para crear un recurso. Como en cualquier petición POST, los datos deben ir incluidos en el cuerpo de la petición.
• PUT: Utilizado para editar un recurso. Al igual que el POST, los datos deben ir en el cuerpo de la petición.
• DELETE: Es la opción para eliminar un recurso
• PATCH: Se utiliza para modificar parcialmente un recurso, aunque se utiliza en muy pocas ocasiones. Normalmente se utiliza simplemente PUT
El uso correcto de estos métodos es básico para considerar una API como REST. No se debería diseñar una API que realice modificaciones sobre un recurso mediante métodos GET, o que elimine elementos mediante un POST, sin embargo, existen numerosos casos de este tipo.
4. Hipervínculos.
Por último, nuestra respuesta puede incluir hipervínculos hacia otras acciones que podamos realizar sobre los recursos. Normalmente se incluyen en el mismo contenido de la respuesta, así si por ejemplo, nuestra respuesta es un objeto en JSON, podemos añadir una propiedad más con los hipervínculos a las acciones que admite el objeto.
Vamos a utilizar Django y su paquete Django REST framework (DRF) para el desarrollo de nuestra API. Django es un framework web de alto nivel, escrito en Python, que ayuda al desarrollo rápido y a un diseño limpio y pragmático. Pone énfasis en el re-uso, la conectividad y extensibilidad de componentes, y el desarrollo rápido. Estas máximas están también en DRF, es una librería que nos permite construir un API REST sobre Django de forma sencilla. Ofreciendo una alta gama de métodos y funciones para el manejo, definición y control de nuestros recursos. Por lo que vamos a poder tener una API RESTful, en muy poco tiempo, generando los servicios de una de las maneras que proporciona este framework.
Suponemos que tenemos un proyecto Django con sus modelos ya creados, y hemos instalado convenientemente DRF. Vamos a ilustrar este ejemplo con el modelo 'programador'.
from django.db import models
class Programmer(models.Model):
El primer paso es crear serializadores de nuestros modelos, en un archivo serializers.py en cada una de nuestras apps de Django.
Ejemplo con Django REST-framework
Suponemos que tenemos un proyecto Django con sus modelos ya creados, y hemos instalado convenientemente DRF. Vamos a ilustrar este ejemplo con el modelo 'programador'.
from django.db import models
LANG_CHOICES
= (
('python', 'Python'),
('c', 'C'),
('java', 'Java'),
('php', 'PHP')
)
nick = models.CharField(max_length=16)
first_name = models.CharField(max_length=255)
last_name =
models.CharField(max_length=255)
email = models.EmailField()
program_lang =
models.CharField(max_length=32, choices=LANG_CHOICES)
from
.models import Programmer
from
rest_framework import serializers
class ProgrammerSerializer(serializers.ModelSerializer):
class Meta:
model = Programmer
fields = ('nick', 'email',
'first_name', 'last_name', 'program_lang')
A continuación, utilizaremos las clases basadas en vistas genéricas, que proporciona DRF, para realizar los servicios, quizá añadiendo un archivo api.py para separarlas de las vistas convencionales incluidas en views.py
from
.serializers import ProgrammerSerializer
from
.models import Programmer
from
rest_framework import generics
class
ProgrammerList(generics.ListCreateAPIView):
queryset = Programmer.objects.all()
serializer_class = ProgrammerSerializer
class
ProgrammerDetail(generics.RetrieveUpdateDestroyAPIView):
queryset = Programmer.objects.all()
serializer_class = ProgrammerSerializer
Por último, incluiremos las urls de nuestra API RESTful, en urls.py:
from django.conf.urls.defaults import url
from .api import
ProgrammerList, ProgrammerDetail
urlpatterns = [
url(r'^programmers/$',
views.ProgrammerList.as_view()),
url(r'^programmers/(?P<pk>[0-9]+)/$',
views.ProgrammerDetail.as_view()),
]
Para la primera url, el método GET nos devolvería la lista de programadores, mientras que el POST nos permitiría la creación de uno nuevo. La segunda realizaría todas las operaciones, sobre el objeto indicado, por la clave primaria en el parámetro de la url. GET para obtenerlo, PUT o PATCH para modificarlo, o DELETE para borrarlo.Para configurar nuestra API, basta añadir a settings.py un diccionario con toda la información. Clases renderizadoras, parseadoras, de permisos, para autentificación, paginadores, uso de filtros, formatos de fecha y hora, etc ...
REST_FRAMEWORK = {
'DEFAULT_RENDERER_CLASSES': (
'rest_framework.renderers.JSONRenderer',
),
'DEFAULT_PARSER_CLASSES': (
'rest_framework.parsers.JSONParser',
),
'DEFAULT_AUTHENTICATION_CLASSES': (
'rest_framework.authentication.TokenAuthentication',
),
'DEFAULT_PERMISSIONS_CLASSES': (
'rest_framework.permissions.IsAuthenticated',
),
}
Con esto indicamos que, tanto llamadas como respuestas, serán incluidas en formato JSON, además de requerir un Token para poder obtener estas respuestas.El resultado es, que con unas pocas líneas de código tenemos los servicios de nuestra API RESTful preparados para ser consumidos por cualquier software externo. A partir de aquí, programar los detalles específicos de cada proyecto que tanto tiempo requieren, pero gracias a Django y DRF, hemos agilizado el desarrollo del grueso de nuestra API y podremos dedicar parte de ese tiempo a estas otras tareas.
No hay comentarios:
Publicar un comentario