Como Desarrollar Aplicabiones Web Con API REST y GRAPHLQ

UNIVERSIDAD MAYOR DE SAN SIMON
FACULTAD DE CIENCIAS Y TECNOLOGIA

DIRECCIÓN DE POSGRADO
COMO DESARROLLAR APLICACIONES WEB

CON API REST Y GRAPHQL
TRABAJO FINAL PRESENTADO PARA OBTENER EL CERTIFICADO

DE DIPLOMADO EXPERTO EN DESARROLLO DE APLICACIONES
EMPRESARIALES VERSIÓN I
.
POSTULANTE : Ronal Giovanny Delgadillo Hinojosa

TUTOR : Ing. Edson Ariel Terceros Torrico
Cochabamba – Bolivia
2018
Dedicado a mis padres,
ejemplo de virtudes y
perseverancia.
Índice de Contenidos
Resumen .........................................................................................................................................................1
Introducción ...................................................................................................................................................2
1. Generalidades ........................................................................................................................................4
1.1. Antecedentes Generales ................................................................................................................4
1.2. Antecedentes Específicos ...............................................................................................................4
2. Metodología ...........................................................................................................................................6
3. Desarrollo de Aplicaciones Web con API REST .......................................................................................6
3.1. REST ................................................................................................................................................6
3.2. Recursos, Representaciones y Solicitudes .....................................................................................6
3.3. Restricciones ..................................................................................................................................7
3.3.1. Cliente - Servidor ....................................................................................................................7
3.3.2. Sin Estado (Stateless) .............................................................................................................7
3.3.3. Cacheable ...............................................................................................................................8
3.3.4. Interfaz Uniforme ...................................................................................................................8
3.3.5. Sistema de Capas....................................................................................................................8
3.3.6. HATEOAS ................................................................................................................................9
3.4. Establecer cómo desarrollar un servicio web con REST .................................................................9
3.4.1. Diseñando un Servicio Web RESTful ....................................................................................10
3.4.2. Jersey: JAX-RS .......................................................................................................................18
3.4.3. Arquitectura de Servicios Web .............................................................................................25
3.4.4. Capa de Persistencia.............................................................................................................26
4. Desarrollo de Aplicaciones Web Usando GraphQL ..............................................................................28
4.1. Que es GraphQL ...........................................................................................................................28
4.2. Historia de GraphQL .....................................................................................................................28
4.3. Consultas y Resultados Precisos...................................................................................................29
4.4. Muchos recursos con una solicitud ..............................................................................................30
4.4.1. Alias ......................................................................................................................................31
4.4.2. Fragmentación......................................................................................................................31
4.4.3. Variables ...............................................................................................................................32
4.4.4. Directivas ..............................................................................................................................33
4.4.5. Mutaciones ...........................................................................................................................34
4.5. El Sistema de Tipo ........................................................................................................................34
4.5.1. Tipos de Objetos...................................................................................................................34
4.5.2. Tipos Escalares .....................................................................................................................35
4.5.3. Tipos de Consulta y Mutaciones...........................................................................................35
4.5.4. Tipos de Suscripción .............................................................................................................35
4.5.5. Tipos de Interfaz y Unión .....................................................................................................35
4.5.6. Tipos de Entrada...................................................................................................................36
5. REST vs. GraphQL .................................................................................................................................36
5.1. Consultas ......................................................................................................................................36
5.2. Uso de la API.................................................................................................................................37
5.3. Caché ............................................................................................................................................38
5.4. Evolución de la API .......................................................................................................................38
5.5. GraphQL o REST............................................................................................................................39
6. Conclusiones.........................................................................................................................................40
7. Bibliografía ...........................................................................................................................................41
Índice de Figuras
Figura 1: Arquitectura del Servicio web .......................................................................................................25
Figura 2: Consulta de GraphQL ....................................................................................................................30
Figura 3: Consulta GraphQL con sub-campo Friends ...................................................................................30
Figura 4: Consulta GraphQL con Argumentos ..............................................................................................30
Figura 5: Consulta GraphQL con Alias ..........................................................................................................31
Figura 6: Consulta GraphQL con Fragmentos ..............................................................................................32
Figura 7: Consulta GraphQL con Variables ...................................................................................................33
Figura 8: Consulta GraphQL con Directivas ..................................................................................................33
Figura 9: Consulta GraphQL con Mutaciones ...............................................................................................34
Índice de Tablas
Tabla 1: Representación XML de un usuario ................................................................................................12
Tabla 2: Representación XML de una lista de usuarios ................................................................................13
Tabla 3: Representación XML de un mensaje ..............................................................................................13
Tabla 4: Representación de una lista de mensajes ......................................................................................14
Tabla 5: Representación JSON de un usuario...............................................................................................15
Tabla 6: Representación JSON de una lista de usuarios...............................................................................15
Tabla 7: Representación JSON de un mensaje .............................................................................................16
Tabla 8: Representación JSON de una lista de mensajes .............................................................................17
Tabla 9: Ejemplo anotación @Path ..............................................................................................................19
Tabla 10: Ejemplo anotación @Path con variable .......................................................................................19
Tabla 11: Ejemplo anotación @GET .............................................................................................................19
Tabla 12: Ejemplo anotación @POST ...........................................................................................................20
Tabla 13: Ejemplo anotación @PUT .............................................................................................................20
Tabla 14: Ejemplo anotación @DELETE .......................................................................................................20
Tabla 15: Ejemplo @GET lista de usuarios ...................................................................................................21
Tabla 16: Ejemplo @GET lista de mensajes .................................................................................................21
Tabla 17: Ejemplo de variables.....................................................................................................................22
Tabla 18: Ejemplo de multiples variables .....................................................................................................22
Tabla 19: Ejemplo anotación @Consumes ...................................................................................................23
Tabla 20: Ejemplo anotación @Produces ....................................................................................................24
Tabla 21: Formulario para crear Nuevo Usuario ..........................................................................................24
Tabla 22: Ejemplo anotación @FormParam ................................................................................................25
Tabla 23: Funciones Básicas CRUD para Db4 ...............................................................................................27
Resumen
REST (Representational State Transfer – Transferencia de Estado Representacional) cambió por

completo la ingeniería de software a partir del 2000. Este nuevo enfoque de desarrollo de
proyectos y servicios web fue definido por Roy Fielding, el padre de la especificación HTTP y uno
de los referentes internacionales en todo lo relacionado con la Arquitectura de Redes.
En la actualidad la mayoría de las aplicaciones disponen de una API REST para la creación de
servicios profesionales. Hay cientos de empresas que generan negocio gracias a REST y las
APIs REST. Sin ellas todo este crecimiento sería prácticamente imposible. Esto es así porque
REST es el estándar más lógico, eficiente y habitual en la creación de APIs para servicios de
internet.
Pero recientemente fueron observadas algunas limitaciones en el uso de REST, la necesidad de

avanzar más rápido en productos cada vez más complejos, más allá de un simple CRUD, han
empujado a un cambio en la forma en que se interactúan con las APIs. Aquí es donde surge
GraphQL, un fuerte candidato a sustituir a REST, sobre todo en el ecosistema de APIs para
aplicaciones en dispositivos móviles.
Por lo tanto, la presente monografía pretende explicar cómo desarrollar aplicaciones web usando
API REST y GraphQL para comprender de forma más sencilla las diferencias entre ambas
tecnologías y de esta forma tener conocimientos más sólidos a la hora de decidir usar una de
estas tecnologías.
1
Introducción
La relación entre internet y sus usuarios ha crecido y evolucionado significativamente con el paso
del tiempo. En sus inicios el internet solo proveía contenido estático: páginas HTML que
solamente mostraban texto estructurado, imágenes y enlaces. Pero ahora los usuarios pueden
interactuar con las páginas, por medios como el chat, foros, email, redes sociales, etc.
Desde los años 90 el internet ha tenido una masiva expansión originado por un constante
incremento de usuarios. El gran incremento de usuarios también atrajo la atención de las
compañías, quienes han intentado crear servicios o mover sus negocios al internet. Debido a la
necesidad de consumir y manipular la información, algunas compañías como los ISPs, crearon
portales para integrar y clasificar su información, de esta manera los usuarios podrían usarlos
como un solo punto de acceso.
Junto con la evolución del internet, la tecnología también tuvo un gran avance, hoy en día vivimos
en un mundo lleno de tecnología. Casi todo el mundo es miembro de una red social como
Facebook, Twitter o LinkedIn y tiene un perfil público en internet. Además, con la aparición de los
teléfonos inteligentes, la forma de comunicación en la sociedad sufrió un cambio significativo. Los
primeros dispositivos portátiles han iniciado una gran popularidad, desde bandas inteligentes
(smartbands) hasta joyas inteligentes (Smart Jewellery), sin olvidar relojes y gafas. Cada
dispositivo ha empezado a interconectarse y conectarse al internet. La gran mayoría de las
compañías y expertos en tecnología están de acuerdo que de aquí a un tiempo millones de
dispositivos estarán conectados a internet lo que se denomina como el IoT (The Internet of Things
– El Internet de las Cosas).
Debido a esta evolución del internet, las redes sociales, la aparición de dispositivos inteligentes
móviles y del creciente número de usuarios, se vio la necesidad de contar con una arquitectura
simple y sencilla que permita a las compañías mostrar sus productos en diferentes dispositivos e
interactuar con otras páginas y usuarios, esa arquitectura es la denominada API.
Un API (Application Programming Interface – Interfaz de Programación de Aplicaciones) puede

proporcionar un gancho para que colegas, socios y desarrolladores externos accedan a datos y
servicios para crear aplicaciones rápidamente como por ejemplo aplicaciones para iPhone. Las
APIs de Twitter y Facebook son ejemplos famosos. Existen APIs que son abiertas a cualquier
desarrollador, APIs que están abiertas solo a los socios, y APIs que se usan internamente para
ayudar a administrar mejor el negocio y facilitar la colaboración entre equipos. (Jacobson, Brail,
& Woods, 2012)
2
Un API, entonces es en esencia un contrato. Una vez que dicho contrato es implementado, los
desarrolladores son tentados a usar la API porque saben que pueden confiar en ella. El contrato
incrementa la confidencialidad, el cual incrementa el uso. El contrato también hace la conexión
entre proveedor y consumidor mucho más eficiente ya que las interfaces son documentadas,
consistentes y predecibles. (Jacobson, Brail, & Woods, 2012)
Una de las arquitecturas preferidas para crear APIs y que ha ganado mucha popularidad es REST
por lo simple y fácil que es crear un API, pero recientemente se vieron algunas limitaciones en el
uso de REST, especialmente en dispositivos móviles y es ahí donde entra lo que se conoce como
GraphQL que es un lenguaje de consultas para los APIs. Al ser una tecnología casi nueva no se
tiene mucha información al respecto, por lo que la presente monografía pretende ayudar al lector
con esto.
El objetivo y la motivación de esta monografía es proveer una investigación de cómo desarrollar

un API usando la arquitectura REST y también al mismo tiempo usando lo que es GraphQL,
investigación que podría satisfacer la falta de información sobre el mismo.
El resultado de la siguiente monografía ayudará a las personas que quieren implementar un API
o aplicación web, a tener más conocimiento sobre lo que es el desarrollo de un API con REST
API y GraphQL.
Se dará una explicación de lo que es REST API y GraphQL, las características de REST,
GraphQL y una explicación con ejemplos de código de cómo desarrollar servicios web usando
ambas arquitecturas.
El lenguaje de programación que se usará será Java, no será necesario una interfaz de usuario
porque lo que se pretende mostrar es el desarrollo del API.
3
1. Generalidades
1.1. Antecedentes Generales
API viene del inglés que significa Application Programming Interface (Interfaz de
Programación de Aplicaciones). Un API ayuda a exponer un servicio empresarial o un activo
empresarial a los desarrolladores que están construyendo una aplicación. Aplicaciones
pueden ser instalados y accedidos desde una variedad de dispositivos, tales como teléfonos
inteligentes, tablets, kiosks, consolas de juegos, autos, y de más dispositivos. La API de
Google Maps usada para localizar lugares en un mapa, la API de Facebook para juegos o
compartir contenido, y el API de Amazon para tener información de productos son algunos
ejemplos de APIs. Los desarrolladores usan estas APIs para crear aplicaciones innovadoras
y geniales, que pueden enriquecer la experiencia de usuario. Por ejemplo, los desarrolladores
pueden usar las APIs de diferentes compañías de turismo para construir una aplicación que
compare y muestre los precios de los mismos hoteles de las diferentes compañías de turismo.
De esta forma el usuario podrá tomar una buena decisión y registrarse en el hotel a través de
la compañía que provee la mejor oferta.
Un API es una interfaz de software a software que define un contrato para las aplicaciones
para comunicarse unos a otros sobre una red sin la necesidad de la interacción del usuario.
1.2. Antecedentes Específicos
El termino REST viene de la disertación PhD de Roy Fielding, publicado en 2000, y significa
Representational State Transfer - Transferencia de Estado Representacional. REST por sí
mismo no es una arquitectura, REST es un conjunto de restricciones que, al ser aplicados al
diseño de un sistema, crea un estilo arquitectónico de software. Al implementar todas las
pautas de REST definidas en el trabajo de Fielding, se termina con un sistema que tiene roles
específicos para los datos, componentes, hipervínculos, protocolos de comunicación y datos
de los consumidores.
Fielding llego a REST evaluando todos los recursos de redes y tecnologías disponibles para
crear aplicaciones distribuidas. Sin restricciones todo y nada vale, lo que nos lleva a
desarrollar aplicaciones que son difíciles de mantener y extender. Con esto en mente él
observó en un documento de estilos arquitectónicos de aplicaciones distribuidas que
empezaba con lo que él llama el null space – el espacio nulo, el cual representa la
disponibilidad de cada tecnología y cada estilo de desarrollo de aplicaciones sin reglas o
límites – y termina con las siguientes restricciones que definen un sistema RESTful.
• Debe ser un sistema Cliente – Servidor.

4
• Tiene que ser Stateless – Sin Estado, no debería ser necesario mantener la sesión del
usuario, en otras palabras, cada petición debe ser independiente de otros.
• Tiene que soportar un sistema de cacheo, la infraestructura de red debe soportar

caché en diferentes niveles.
• Tiene que ser uniformemente accesible, cada recurso debe tener una dirección única
y un punto de acceso válido.
• Tiene que estar en capas, debe soportar la escalabilidad.
• Debe proporcionar código a pedido, aunque ésta es una restricción opcional, las
aplicaciones pueden ser extensibles en tiempo de ejecución al permitir la descarga de
código bajo demanda, por ejemplo, Applets de Java.
(Sandoval, 2009)
Ahora se hablará un poco de GraphQL. GraphQL es un lenguaje de consultas (queries)

que permite definir qué datos pedirle a un API. Se trata de una tecnología que Facebook
empezó a desarrollar en 2012, aunque fue anunciada y liberada en 2015.
GraphQL proporciona una interfaz común entre aplicaciones cliente – servidor para
obtener y manipular datos, GraphQL es definido como un lenguaje de consulta de datos
en tiempo de ejecución, es un lenguaje que se puede enseñar a un cliente de software, el
cliente o la aplicación puede entonces comunicarse con el servicio de back-end que
también entiende GraphQL para pedir datos, y es en tiempo de ejecución, porque
GraphQL es una capa de ejecución que una aplicación de servidor puede usar para
comprender y responder a cualquier solicitud realizada con GraphQL. Esta capa actúa
como un simple traductor del lenguaje GraphQL.
(Buna, 2016)
GraphQL surge con la idea de resolver algunos problemas que tienen los Servicios REST.
La idea original era permitir que los clientes de los servicios REST pudieran decidir qué
información le interesa a un particular end-point. Quienes han trabajado desarrollando
servicios REST, sabrán que muchas veces la cantidad de información que termina
devolviendo un end-point particular es enorme, y no todos los casos de uso la consumen
en su totalidad.
Estos son algunas diferencias entre GraphQL y REST
• REST requiere varias consultas, GraphQL requiere solo una.
5
• Con REST, se consulta o muchas o muy poca información. Con GraphQL se
consulta exactamente lo que se necesita
• REST por lo general se convierte en un laberinto de end-points mal documentados.

GraphQL es altamente tipado y auto-documentado.
2. Metodología
Para el presente trabajo se utilizará los siguientes métodos de investigación:
• Método Bibliográfico, debido a que se realizará la lectura y compilación de libros

relacionados al tema de estudio.
• Método Analítico, debido a que se procederá a revisar y analizar ordenadamente

documentos relacionados al tema de estudio, para la redacción de la presente monografía.
3. Desarrollo de Aplicaciones Web con API REST
Los aspectos más importantes de REST son: está basada en un conjunto de restricciones que al
ser aplicadas correctamente da como resultado una arquitectura REST bien estructurada, que
facilita la creación de un API REST
3.1. REST
REST viene del inglés Representational State Transfer que significa Transferencia de Estado
Representacional, fue por primera vez introducido al mundo en el año 2000 por Roy Fielding
en su disertación doctoral (Doglio, 2015). En los últimos años REST ha sido el modelo de
diseño de servicios web dominante debido a su simplicidad sobre otros diseños disponibles
en ese entonces. REST es un concepto arquitectónico que tiene como objetivo, ayudar a crear
y organizar sistemas, lo que significa que no es un estándar con reglas escritas en piedra,
sino un estilo para mostrar cómo se comporta un buen sistema (Doglio, 2015). La arquitectura
tiene como objetivo crear sistemas de rendimiento, transformables y duraderos.
3.2. Recursos, Representaciones y Solicitudes
Como su nombre sugiere REST transfiere una representación de sus recursos. Los recursos
definen el tipo de información transferida, las acciones y servicios de un sistema. Puede ser
cualquier elemento conceptualizado, un texto o una imagen, por ejemplo. El cliente envía un
encabezado específico (header) que solicita un recurso al servidor. La API es responsable de
encontrar la mejor representación de ese recurso en el lado del servidor. Los recursos se
pueden representar de muchas formas. Los datos se pueden representar, por ejemplo, como
6
un archivo JSON o XML, y un recurso puede tener múltiples representaciones. El cliente leerá
y analizará la información y solicitará la forma más adecuada del recurso. (Doglio, 2015)
Un recurso tiene un identificador en forma de una URL (Doglio, 2015). Las URLs utilizadas
deben ser lógicas y accesibles por otras partes del sistema, así como también ser únicas para
un recurso específico. Los recursos también tienen metadatos para describirlos, por ejemplo,
un tipo de contenido. Los recursos se consultan con el identificador URL y una solicitud
(Request). La solicitud GET se utilizará para consultas con fines de solo lectura y para
consultas más complejas que alteran la etapa de los datos (Crear, Actualizar y Borrar) a
menudo se usa POST. (Uzayr, 2016).
• GET /api/resource.json
• GET /api/resource.xml
Además de los verbos mencionados anteriores, PUT se usa para crear-editar y DELETE para
eliminar un recurso. Algunas acciones, como buscar y filtrar recursos, no se realizan
directamente con ninguna de las solicitudes mencionadas. Estas acciones complejas se
realizan con un signo "?" Que se puede aplicar a todos los verbos. (Doglio, 2015)
• GET /api/resource?q=[TERMINO DE BUQUEDA]
• GET /api/resource?filters=[LISTA DE FILTROS SEPARADAS POR COMA]
3.3. Restricciones
REST define un sistema con restricciones. Estas restricciones se discuten en los siguientes
subcapítulos. Al agregar las siguientes restricciones una a una, desde la primera hasta la
última, a todos los componentes, se alcanzará la armonía en las interacciones del sistema.
(Doglio, 2015).
3.3.1. Cliente - Servidor
Esta restricción describe la naturaleza básica de las APIs. El servidor está a cargo de los
servicios, y la solicitud de sus servicios. El cliente realiza las solicitudes al servidor con
respecto a sus servicios. Esto separa el código del front-end (Código del lado del cliente)
y el código del lado del servidor que almacena y procesa los datos. Permitiendo así un
desarrollo independiente y una evolución para ambos. (Doglio, 2015)
3.3.2. Sin Estado (Stateless)
Las solicitudes provenientes del cliente deben incluir toda la información necesaria para
que el servidor entienda completamente esa solicitud. Esto mejorará la supervisión y
7
confiabilidad del sistema. También significa que los datos no se almacenarán entre
solicitudes, lo que se traduce en una liberación de recursos mucho más rápida y una
implementación más sencilla. (Doglio, 2015).
La desventaja de la restricción es la sobrecarga potencial de las solicitudes. Cuando se

requiere toda la información para las solicitudes del servidor, es fácil obtener datos en
exceso y generar tráfico adicional.
3.3.3. Cacheable
Las respuestas a las solicitudes deben almacenarse en caché. Todos los datos solicitados
ya listos o consultadas anteriormente se pueden obtener desde la capa de caché que se
encuentra en el cliente o en el servidor. Esto resulta en un rendimiento más rápido. La
desventaja de esto puede ser que, si el almacenamiento en caché está mal diseñado,
posiblemente los datos devueltos pueden dejar de estar actualizados. (Doglio, 2015).
3.3.4. Interfaz Uniforme
Establecer una interfaz uniforme para los componentes de un sistema simplificará las
interacciones entre el cliente y el servidor. Deben utilizarse identificadores únicos para los
recursos y acciones CRUD (create, retrieve, update, delete - crear, recuperar, actualizar,
eliminar) proporcionadas para las solicitudes, dando a los clientes independientes un
conjunto claro de reglas a seguir al implementar la aplicación (Doglio, 2015). Teniendo en
cuenta que HTTP no es el único protocolo para REST, esto se puede hacer con rutas
HTTP únicas para cada recurso (/api/resource), así como también usando verbos HTTP
(GET, PUT, POST, DELETE) para las interacciones.
Esta restricción puede tener su lado negativo. La interfaz uniforme estandarizará todas las
comunicaciones, incluso si una forma más adecuada estaría disponible para una
determinada pieza de software. Cuando se usa REST con mayor frecuencia y se aleja de
los sistemas basados en web, donde se optimiza REST, el rendimiento puede
perjudicarse. (Doglio, 2015).
3.3.5. Sistema de Capas
Separar los componentes del sistema en múltiples capas puede simplificar el sistema,
mejorar la seguridad y nivelar las cargas de tráfico. También permite añadir nuevas capas
y eliminar las existentes o modificarlas sin alterar con todo el sistema.
8
3.3.6. HATEOAS
HATEOAS es la abreviatura de Hypermedia as the Engine of Application State –

Hypermedia como el Motor del Estado de una Aplicación y es una restricción de REST
que se distingue de otras arquitecturas de red. A diferencia de muchas otras arquitecturas
con interacciones guiadas solo en la documentación o el lenguaje, permite al cliente
interactuar completamente con una aplicación a través de enlaces de hipermedia sin
conocimiento previo de como interactuar con la aplicación. HATEOAS tiene como objetivo
proporcionar sistemas de longevidad y buenas posibilidades para evolucionar.
HATEOAS se asemeja a un proceso familiar de ingresar a una página web. El cliente

tendrá una URL fija, un end-point raíz para ingresar a la aplicación. Allí se proporciona un
conjunto de enlaces para posibles primeros pasos, una lista de recursos. Cada recurso
tiene metadatos, en los que debe haber un conjunto de enlaces hipermedia. Estos enlaces
le dicen al cliente que hacer con ese recurso, Esto significa que todos los próximos pasos
con respecto a ese recurso están ahí para el cliente. Así es como el cliente realiza la
transición a través de la aplicación y posibilita la manipulación de las representaciones de
los recursos. Los metadatos también incluyen la posibilidad de especificar el tipo de
contenido de una representación de un recurso, si hay más de uno. El cliente puede elegir
el que mejor se adapte para el caso de uso particular. (Doglio, 2015).
El end-point raíz expone enlaces que se utilizan a lo largo de la transición del cliente en
el sistema. No todos los enlaces son accesibles desde todo end-point. La API solo
devuelve los enlaces necesarios para ese caso de uso particular. El cliente aún tendrá
acceso a todo lo expuesto en el end-point raíz para mostrar información al usuario final.
(Doglio, 2015).
HATEOAS mejora significativamente el desacoplamiento entre el cliente y el servidor.

También permite cambios en los recursos y funcionalidades en el alado del servidor sin
afectar al cliente. Por lo tanto, los clientes del sistema REST pueden iniciar interacciones
conociendo solo un end-point: el end-point raíz y seguir interactuando a través de la
evolución del lado del servidor sin complicaciones.
3.4. Establecer cómo desarrollar un servicio web con REST
El proceso de desarrollo RESTful sigue paradigmas de desarrollo tradicionales. Sin embargo,

con los servicios web RESTful, primero debemos analizar los requisitos de recursos, diseñar
la representación para nuestros recursos, identificar las URLs y, por último, preocuparnos por
las tecnologías de implementación. (Sandoval, 2009)
9
3.4.1. Diseñando un Servicio Web RESTful
El diseño de servicios web RESTful no es diferente del diseño de aplicaciones web

tradicionales. Todavía se tiene los requisitos del negocio, todavía se tiene usuarios que
quieren hacer operaciones con los datos, y todavía se tiene restricciones de hardware y
arquitecturas de software con las que lidiar, sin embargo, la principal diferencia es que
fijamos los requisitos para desentrañar recursos y olvidamos las acciones específicas que
se deben tomar en estos recursos. (Sandoval, 2009)
Los principios de diseño de Servicios Web RESTful se pueden resumir en los siguientes
cuatro pasos:
1. Recopilación de requisitos: este paso es similar a las prácticas tradicionales de

recopilación de requisitos de software.
2. Identificación de recursos: Este paso es similar a DOO (Diseño Orientado a

Objetos) en el que identificamos objetos, pero no nos preocupamos por la
mensajería entre objetos.
3. Definición de Representación de Recursos: debido a que intercambiamos

representación entre clientes y servidores, debemos definir qué tipo de
representación necesitamos usar. Normalmente, usamos XML, pero JSON ha
ganado popularidad. Eso no quiere decir que no se pueda usar cualquier otra
forma de representación de los recursos; por el contrario, se podría usar XHTML
o cualquier otra forma de representación binaria.
4. Definición de la URI: Con los recursos implementados, necesitamos definir la API,

que consiste en URIs para que los clientes y servidores intercambien
representaciones de recursos.
Este proceso de diseño no es estático. Estos son pasos iterativos que gravitan alrededor
de los recursos. Por ejemplo: durante el paso de definición de la URI se descubre que una
de las respuestas de la URI no está cubierta en uno de los recursos que se han
identificado. Luego se vuelve a definir un recurso adecuado, sin embargo, en la mayoría
de los casos, se encuentra que los recursos que ya se tienen cubren la mayoría de las
necesidades, y solo se tiene que combinar los recursos existentes en un meta-recurso
para atender el nuevo requisito. (Sandoval, 2009)
El Servicio Web RESTful que se diseñará en esta monografía es una red social similar a
Twitter, este ejemplo y el código fueron obtenidos del libro RESTful Java Web Servicies
de Jose Sandoval.
10
3.4.1.1. Requisitos del Servicio Web de Ejemplo
Al igual que con cualquier aplicación, se comenzará enumerando los principales

requisitos del negocio, para los cuales se tiene los siguientes casos de uso (estas son
las funciones principales de la aplicación):
• Un usuario web crea una cuenta con un nombre de usuario y contraseña (crear
una cuenta significa que el usuario ya está registrado).
• Los usuarios registrados publican entradas de blog en sus cuentas. Limitamos

los mensajes a 140 caracteres.
• Los usuarios registrados y no registrados ven todas las entradas del blog.
• Los usuarios registrados y no registrados ven los perfiles de usuario.
• Los usuarios registrados actualizan sus perfiles de usuario.
• Los usuarios registrados y no registrados buscan términos en todas las

entradas de Blog.
3.4.1.2. Identificación de Recursos
Fuera de los casos de uso mencionados anteriormente, ahora se necesita definir los
recursos del servicio. De la lectura de los requisitos se ve que se necesitan usuarios
y mensajes. Los usuarios aparecen de dos maneras: un solo usuario y una lista de
usuarios. Además, los usuarios pueden publicar entradas de Blog en forma de
mensajes de no más de 140 caracteres. Esto significa que se necesita recursos para
un solo mensaje y una lista de mensajes. En resumen, se identifican los siguientes
recursos:
• Usuario
• Lista de Usuarios
• Mensaje
• Lista de Mensajes
(Sandoval, 2009, pág. 71)
3.4.1.3. Definición de Representación
Una representación es un mapeo temporal de un recurso en el momento de una

solicitud. Además, una representación se transmite entre clientes y servidores a través
11
de HTTP. Debido a la flexibilidad de HTTP, cualquier flujo binario puede ser
transferido, pero se recomienda usar estructuras como XML y JSON.
Un servicio web RESTful bien diseñado debe proporcionar múltiples representaciones

de recursos. No se puede asumir que solo los navegadores web accederán a las APIs
públicas o que solo el tipo de cliente que se identifica en el proceso de recopilación de
requisitos utilizará los servicios.
Llegar al formato de representación ideal es una cuestión del proceso de diseño. Se

debe tener en cuenta lo que hace el servicio y para que se utilizarán los recursos de
los clientes. El formato de representación más seguro es, por lo tanto, XML. Esto es
por lo que los servicios web son conocidos por: transferir flujos XML a través de
protocolos de transporte web. Más importante aún, la mayoría de los lenguajes de
programación ya tienen bibliotecas disponibles para analizar flujos XML.
Finalmente, se debe tener en cuenta la vinculación de las representaciones. La

vinculación de la representación significa que los servicios web permiten la detección
de recursos, de modo que los recursos se vinculan con otros recursos (lo que
actualmente se conoce como transferencia HATEOAS o (Hypermedia As The Engine
Of State – Hipermedia Como El Motor de Transferencia de Estado). Por ejemplo, la
URI para una lista de usuarios devuelve una estructura de usuarios con cada elemento
en la lista que tienen un URI directo a cada elemento en el servicio (un enlace a un
usuario). (Sandoval, 2009, pág. 72)
3.4.1.3.1. Representaciones en XML
Del análisis, se identificarán dos tipos de recursos: usuarios y mensajes. Como

parte de las heurísticas que se describió anteriormente, se debe definir cómo será
la representación. Las siguientes representaciones son las estructuras que se
tienen que implementar cuando realmente se codifique el servicio web.
Usuarios
Primero se definirá una representación de usuario de la siguiente manera:
<user>
<username></username>
<password></password>
<link></link>
</user>
Tabla 1: Representación XML de un usuario
Fuente: (Sandoval, 2009)
12
Como parte de un recurso de usuario, se almacena solo un nombre de usuario y
una contraseña. El nombre de usuario es único en el contexto del sistema y se
utiliza para identificar de forma única a cada usuario. El elemento de enlace, que
apunta al servicio web, se asigna cuando se crea el recurso o cuando se crea una
representación para el transporte (para el servicio de muestra, se permite que el
back-end cree el enlace).
Ahora se definirá una lista de usuarios de la siguiente manera:
<users>
<count></count>
<link></link>
<user>
<link></link>
</user>
...
<user>
<link></link>
</user>
</users>
Tabla 2: Representación XML de una lista de usuarios
Esta estructura XML declara una lista de usuarios que se almacena en un

elemento XML <users>. Se utiliza puntos suspensivos o … para mostrar que se
puede tener más de un usuario en la lista. (Sandoval, 2009)
Mensajes
Primero se definirá una solo entrada de blog o mensaje de la siguiente manera:
<message>
<messageID></messageID>
<content></content>
<link></link>
<user>
<link></link>
</user>
</message>
Tabla 3: Representación XML de un mensaje
13
Un mensaje necesita un ID de mensaje, el cuerpo del mensaje (el elemento de
contenido) y el usuario que publicó el mensaje. Tenga en cuenta que, dependiendo
de lo que se esté haciendo con el mensaje, no pasamos toda la información del
recurso de un lado a otro. Por ejemplo, cuando se está creando un mensaje en la
capa del cliente, no se sabe cuál es el valor para messageID. Por lo tanto, todavía
se debe pasar la estructura del mensaje al servicio, pero el servicio web sabrá que
cualquier valor de ID de mensaje debe ignorarse, porque, en este caso, lo creará
la capa de almacenamiento.
Finalmente, se definirá una lista de mensajes de la siguiente manera:
<messages>
<count></count>
<link></link>
<message>
<content></content>
<link></link>
<user>
<link></link>
</user>
</message>
...
<message>
<content></content>
<link></link>
<user>
<link></link>
</user>
</message>
</messages>
Tabla 4: Representación de una lista de mensajes
Esta estructura XML contiene una colección de mensajes, y cada mensaje

contiene al usuario que publicó el mensaje. (Sandoval, 2009)
14
3.4.1.3.2. Representaciones en JSON
Se usa los mismos nombres de clave para la representación en JSON, y aún se

tiene solo dos tipos de recursos: usuarios y mensajes. Nuevamente, estas
estructuras son las especificaciones de lo que se necesita devolver para cada
solicitud.
Usuarios
Se define una representación de usuario de la siguiente manera:
{
"user":{
"username":"john",
"password":"password",
"link":"/users/john"
}
}
Tabla 5: Representación JSON de un usuario
Y se define una lista de usuarios de la siguiente manera:
{
"users-result":{
"count":"6",
"users":[
{
"username":"john",
},
...,
{
"username":"jane",
"link":"/users/jane"
}
]
}
}
Tabla 6: Representación JSON de una lista de usuarios
Mensajes
Ahora se definirá una representación de mensaje de la siguiente manera:
15
{
"message":{
"messageID":"some-id",
"content":"some content",
"link":"/messages/some-id",
"user":{
"user":{
"username":"john",
}
}
}
}
Tabla 7: Representación JSON de un mensaje
Y una lista de mensajes de la siguiente manera:
{
"messages-result":{
"count":"6",
"link":"/messages",
"messages":[
{
"messageID":"some-id",
"link":"/messages/some-id",
"user":{
"username":"john",
}
},
...,
{
"messageID":"someid2",
"link":"/messages/some-id2",
"user":{
"username":"jane",
"link":"/users/jane"
}
}
]
}
16
}
Tabla 8: Representación JSON de una lista de mensajes
3.4.1.4. Definición de URI
El siguiente paso implica la definición de URIs. Este es un paso crucial, ya que las
URIs definen la API y es probable que se quiera que el servicio web sea público.
Lo primero que se necesita es una dirección web. En este caso se asume que se
utilizará la máquina de desarrollo que se ejecuta en http://localhost:8080/
La nomenclatura de URI RESTful cae bajo el tema de las plantillas URI y las siguientes
convenciones son ampliamente utilizadas. Primero, para los elementos o
identificadores que no cambian, se encuentra que la palabra clave es parte del URI
real; por ejemplo, se usa users como el URI para una lista de todos los usuarios. En
segundo lugar, se usa claves o palabras clave dinámicas para ser encerrados en { y
}. Aplicando estas convenciones, la lista de URIs para usuarios tiene el siguiente
aspecto: (Sandoval, 2009)
• http://localhost:8080/users: con el método GET, este URI devuelve una lista de

todos los usuarios; con el método POST, se creará un nuevo usuario y la carga
útil es la representación XML de un usuario; no se usa el método PUT; por
último, no se admite el método DELETE para un alista completa de usuarios.
• http://localhost:8080/users/{username}: con el método GET, este URI devuelve

una representación de un usuario con un nombre de usuario de identificador
único; con el método PUT, actualiza un usuario; y con el método DELETE,
borra un usuario.
Y para los mensajes, la lista de URIs es de la siguiente manera:
• http://localhost:8080/messages: con el método GET, esta URI devuelve una

lista de todos los mensajes de todos los usuarios; con el método POST, se
creará un nuevo mensaje, con la representación XML del mensaje como la
carga útil de la solicitud.
• http://localhost:8080/messages/{messageID}: con el método GET, esta URI

devuelve una representación para un mensaje con el identificador único
messageID; con el método DELETE, borra un mensaje; y no se usará los
métodos POST o PUT
17
• http://localhost:8080/messages/users/{username}: con el método GET, esta
URI devuelve una lista de todos los mensajes para un usuario con un nombre
de usuario identificador; no se admiten los métodos POST, PUT o DELETE
(Sandoval, 2009)
3.4.2. Jersey: JAX-RS
En el mundo de los servicios web RESTful, se tienen algunos Frameworks puros de Java
RESTful disponibles. Entre ellos se tiene Jersey, la implementación de referencia de la
API de Java Sun para servicios web RESTful, más conocida comúnmente como JAX-RS.
Para el ejemplo que se está diseñando se usará Jersey para implementar el servicio web.
3.4.2.1. JAX-RS
La tecnología Java siempre fue parte de las soluciones de servicios web, pero se limitó
a WSDL y SOPA. Con la llegada de REST, el proceso de la comunidad de Java (JCP)
inicio el proyecto JAX-RS con el objetivo de crear una API para servicios web RESTful
de Java. La API también se conoce como JAX-311 o JAX-RS. Esta especificación es
utilizada por cualquier persona que desee crear un Framework Java que se adhiera a
todas las restricciones REST que se han analizado.
El uso de anotaciones permite crear recursos de Jersey con la misma facilidad con
que se desarrolla POJOs (Plain Old Java Objects – Objetos de Java Antiguos y
Simples). En otras palabras, se deja la interceptación de las solicitudes HTTP y las
negociaciones al Framework y así concentrarse en las reglas del negocio necesarias
para resolver el problema. (Sandoval, 2009)
3.4.2.2. Anotaciones
El objetivo principal de la especificación JAX-RS es hacer que el desarrollo del servicio

web RESTful sea más fácil de lo que fue en el pasado. Jersey proporciona los
conectores para servicios web a través de anotaciones de Java, las anotaciones
generan automáticamente el código necesario para que las clases las usen para
conectarse sin problemas dentro de marcos específicos. (Sandoval, 2009)
3.4.2.2.1. Recurso Jersey
Un recurso de Jersey es una simple clase de Java dentro del contexto de una
aplicación web que usa la anotación @Path para definir una URI. El valor de la
anotación es el URI relativo al contexto de la aplicación web, tal como se
implementa en el servidor web. (Sandoval, 2009)
18
3.4.2.2.2. URIs
Cada recurso de Jersey tiene una URI que lo señala. Un recurso se identifica con
la anotación @Path.
@Path
Uno de los URI que se definió en la especificación de servicio web es /users (este
URI apunta a la representación de una lista de usuarios). En el código, el uso de
esta anotación se ve de la siguiente manera:
@Path("/users")
public class UsersResource {
}
Tabla 9: Ejemplo anotación @Path
Esta anotación también se utiliza para definir variables en una URI. Si recuerda,
se dijo que una URI para un usuario específico se parece a /users/{username}, así
que en el código esto se ve de la siguiente manera:
@Path("/users/{username}")
public class UserResource {
}
Tabla 10: Ejemplo anotación @Path con variable
3.4.2.2.3. Métodos HTTP
Cada solicitud HTTP hecha a un servicio web es manejada por un método anotado
apropiadamente en una clase de recurso, siempre que la clase de recurso tenga
la anotación @Path definida. Jersey admite las siguientes anotaciones para cada
una de las solicitudes de métodos HTTP. (Sandoval, 2009)
@GET
Una solicitud GET se maneja mediante un método anotado que tiene el siguiente
aspecto:
@Path("/users")
@GET
public String handleGETRequest() {
}
}
Tabla 11: Ejemplo anotación @GET
19
@POST
Una solicitud POST se maneja mediante un método anotado que tiene el siguiente
aspecto:
@Path("/users")
@POST
public String handlePOSTRequest(String payload) {
}
}
Tabla 12: Ejemplo anotación @POST
La solicitud POST tiene un payload que el Framework intercepta y se entrega en
el parámetro payload. El valor del payload podría ser una estructura XML por lo
que se usa un objeto String. Sin embargo, el payload también podría ser un flujo
binario de, por ejemplo, un MIME type image/jpg, por lo que el tipo de objeto para
nuestro payload debe cambiar en consecuencia (por ejemplo, InputStream).
@PUT
Una solicitud PUT se maneja mediante un método anotado que tiene el siguiente
aspecto:
@Path("/users")
@PUT
public String handlePUTRequest(String payload) {
}
}
Tabla 13: Ejemplo anotación @PUT
Similar a la solicitud POST, la solicitud PUT tiene un payload asociado. Que se

almacena en la variable payload.
@DELETE
Una solicitud DELETE se maneja mediante un método anotado que tiene el
siguiente aspecto:
@Path("/users")
@DELETE
public void handleDELETERequest() {
}
}
Tabla 14: Ejemplo anotación @DELETE
20
Rutas Relativas en los Métodos
También se puede tener rutas relativas para cada método desde la ruta raíz
anotada en la definición de la clase. Por ejemplo, esta clase sirve una URI para
/users
@Path("/users")
@GET
}
}
Tabla 15: Ejemplo @GET lista de usuarios
Si se quiere servir la URI /users/messages, por ejemplo, no se necesitaría una

nueva definición de clase, y se podría anotar un nuevo método como sigue:
@Path("/users")
@GET
}
@GET @Path("/messages")
public String handleGETRequestMessages() {
}
}
Tabla 16: Ejemplo @GET lista de mensajes
Ahora se tiene una clase de recurso que maneja solicitudes para /users y
/users/messages/. (Sandoval, 2009)
3.4.2.2.4. Variables URI
@PathParam
Esta anotación es usada junto con @Path y junto con @GET, @POST, @PUT y
@DELETE. En la especificación, se tiene el URI /users/{username}. Se dijo que el
nombre de usuario es una variable, y para obtener su valor de la URI se usa el
@PathParam de esta manera:
21
@Path("/users/{username}")
@GET
public String handleGET(
@PathParam("username") String username) {
// We can use username however we like...
}
@POST
public String handlePOST(
}
@PUT
public String handlePUT(
}
@DELETE
public String handleDELETE(
}
}
Tabla 17: Ejemplo de variables
También se puede usar múltiples variables en las URIs. Por ejemplo, se puede
tener una URI para consultar una lista de usuarios que limite los resultados por
género, edad y dirección, que se parece a /users/{gender}/{age}/{address}.
Entonces la definición del método se vería como sigue: (Sandoval, 2009)
@Path("/users/{gender}/{age}/{address}")
public class UsersResource {
@GET
public String handleGET(
@PathParam("gender") String gender,
@PathParam("age") int age,
@PathParam("address") String address) {
}
}
Tabla 18: Ejemplo de multiples variables
3.4.2.2.5. Formatos de Entrada y Salida
Antes se vio cómo manejar las solicitudes realizadas a un servicio web, ahora se
verá como intercambiar representaciones entrantes y salientes entre clientes y
servidores. Para esto, se tiene las siguientes anotaciones.
22
@Consumes
Esta anotación funciona junto con @POST y @PUT. Le dice al Framework a que
método delegar la solicitud entrante. Específicamente, el cliente establece el
encabezado (header) Content-Type HTTP y el Framework delega la solicitud al
método de manejo correspondiente.
Un recurso puede aceptar diferentes tipos de payloads. Por lo tanto, se usa la

anotación @PUT con múltiples métodos para manejar solicitudes con diferentes
MIME types. Entonces se tiene lo siguiente: un método para aceptar estructuras
XML y un método para aceptar estructuras JSON
Path("/users")
@PUT
@Consumes("application/xml")
public void updateXML(String representation) {
}
@PUT
@Consumes("application/json")
public void updateJSON(String representation) {
}
}
Tabla 19: Ejemplo anotación @Consumes
En este ejemplo se indica al Framework que el método updateXML() acepta un

flujo de entrada application/xml, y el método updateJSON() acepta un flujo de
entrada application/json, que se almacena en la variable representation. Por lo
tanto, un cliente que se conecta al servicio web a través de la URI /users debe
enviar una solicitud PUT que contenga el tipo de encabezado HTTP con un valor
application/xml o application/json. La misma idea es usada para @POST.
(Sandoval, 2009)
@Produces
Esta anotación funciona con @GET, @POST y @PUT. Le permite al Framework
saber qué tipo de representación enviar al cliente.
Específicamente, el cliente envía una solicitud HTTP junto con un encabezado

HTTP de aceptación que se agina directamente al Content-Type que produce el
método. Por lo tanto, si el valor del encabezado HTTP es application/xml, el
método que maneja la solicitud devuelve una secuencia del tipo MIME
23
application/xml. Esta anotación también se puede utilizar con varios métodos en la
misma clase de recurso. Un ejemplo que devuelve las representaciones XML y
JSON es el siguiente: (Sandoval, 2009)
@Path("/users")
@GET
@Produces("application/xml")
public String getXML(String representation) {
}
@GET
@Produces("application/json")
public String getJSON(String representation) {
}
}
Tabla 20: Ejemplo anotación @Produces
3.4.2.2.6. Parámetros
Los servicios web RESTful intercambian representaciones utilizando URIs. Sin

embargo, debido a que a veces se usa tecnologías web y debido a decisiones de
diseño, no siempre se usará representaciones como las estructuras XML. A veces
se necesitará proporcionar otros medios para transferir datos, como formularios
HTML simples. Esto significa que, si un cliente envía una solicitud desde un
formulario HTML, se deberá obtener acceso al conjunto de valores que forma parte
de la solicitud. Aunque no se usa la siguiente anotación en el servicio web, es
posible que desee echarle un vistazo y luego decidir si tiene sentido utilizarla en
sus soluciones.
@FormParam
Esta anotación permite leer los valores de los pares nombre/valor pasados como
parte de una solicitud POST o PUT. Por ejemplo, se tiene un formulario HTML que
contiene los elementos nombre, edad y dirección de la siguiente manera:
<form action="/users" method="POST">

Name: <input type="text" name="name">
Age: <input type="text" name="age">
Address: <input type="text" name="address">
</form>
Tabla 21: Formulario para crear Nuevo Usuario
24
Luego, se usa la anotación @FormParam de la siguiente manera.
@Path("/users")
@POST
@Consumes("application/x-www-form-urlencoded")
public void addUser(
@FormParam("name") String name,
@FormParam("age") int age,
@FormParam("address") String address) {
}
}
Tabla 22: Ejemplo anotación @FormParam
El cliente se conecta a nuestra URI a través de una solicitud POST (o PUT) con el
payload que contiene el conjunto nombre/valor definido en el formulario. Cuando
el Framework maneja la solicitud, se tiene acceso a todos los valores que se
definieron en el método addUser(), tal como se hizo con la anotación
@PathParam. (Sandoval, 2009)
3.4.3. Arquitectura de Servicios Web
El código de este servicio web se divide en tres capas de abstracción, con cada capa
correspondiente a un paquete en el código. Se tendrá una capa web, que contiene las
clases de recursos de Jersey; una capa de negocios, que contiene clases que manejan el
almacenamiento real y la recuperación de recursos; y una capa modelo, que contiene las
clases que se almacenan en nuestra base de datos. Finalmente, para facilitar la
implementación, se usará Db4o para almacenar usuarios y mensajes. La arquitectura
completa se ve como sigue:
Figura 1: Arquitectura del Servicio web

25
Descomponer la implementacion de la aplicación en capas es una práctica común de
ingenieria de software. Con capas de código completamente separadas, las clases se
convierten en componentes que intercambian mensajes entre sí. Por ejemplo, las clases
de recursos en la capa web no hacen mas que manejar la comunicación entre el cliente y
el servidor utilizando el protocolo HTTP y luego delegan el trabajo a la capa de negocios.
La capa de negocios toma las representaciones XML enviadas por los clientes, valida
estas representaciones y las convierte en objetos de valor para lamacenar en una base
de datos. (Sandoval, 2009)
3.4.4. Capa de Persistencia
Para la capa de persistencia se usará Db4o, un motor de base de datos de objetos de

código abierto. Es ligero y fácil de usar: almacena objetos y recupera objetos. Además,
Db4o usa un archivo en el sistema operativo para almacenar datos, por lo tanto, no es
necesario que se ejecute un servidor de base de datos por separado. La siguiente tabla
enumera las cuatro funciones básicas de CRUD que necesita la implementación:
Acción Código de Ejemplo
Create ObjectContainer db = Db4o.openFile("/tmp/db.data");

db.store(new StringBuilder("REST"));
db.close();
Read ObjectContainer db = Db4o.openFile("/tmp/db.data");

ObjectSet<MessageVO> result =
db.queryByExample(new StringBuilder("REST");
db.close();
Delete ObjectContainer db = Db4o.openFile("/tmp/db.data");

db.queryByExample(new String("REST");
if (result.hasNext()) {
StringBuilder tmpString = result.next();
}
db.delete(tmpString);
db.close();
Update ObjectContainer db = Db4o.openFile("/tmp/db.data");

db.queryByExample(new StringBuilder("REST");
26
if (result.hasNext()) {
StringBuilder tmpString = result.next();
}
tmpString.append("ful Java");
db.store(tmpString);
db.close();
Tabla 23: Funciones Básicas CRUD para Db4

27
4. Desarrollo de Aplicaciones Web Usando GraphQL
Los aspectos de GraphQL más importantes son ofrecer una forma más directa, sencilla y eficiente
para obtener exactamente los datos que se requieren utilizando una única solicitud, y al ser un
lenguaje de consulta puede ser utilizado indistintamente en diferentes códigos de programación,
todo esto para facilitar la creación de un API usando GraphQL.
4.1. Que es GraphQL
GraphQL es un lenguaje de consulta de datos para las APIs y en tiempo de ejecución

(runtime) para cumplir esas consultas con sus datos existentes. GraphQL proporciona una
descripción completa y comprensible de los datos en tu API, brinda a los clientes la capacidad
de pedir exactamente lo que necesitan y nada más, hace que sea más fácil evolucionar las
APIs a lo largo del tiempo y permite poderosas herramientas de desarrollo. (graphql.org, s.f.).
GraphQL es un lenguaje que se puede enseñar a una aplicación de cliente de software. La
aplicación puede entonces comunicarse con un servicio back-end, también hablando
GraphQL, para solicitar datos. El lenguaje es parecido a JSON y tiene operación para lectura
de datos (queries - consultas) y escritura de datos (mutations - mutaciones). Las operaciones
son cadenas para las cuales el servicio GraphQL puede responder en el formato deseado, a
menudo JSON. (Buna, 2016, pág. 1).
GraphQL es una capa en tiempo de ejecución, escrito en cualquier lenguaje de programación

para una aplicación de servidor para que comprenda y responda a las solicitudes de GraphQL.
La capa define un esquema basado en gráficos de posibles servicios de datos para el cliente.
Los servicios de back-end hablan su propio lenguaje y esta capa se puede implementar sobre
la lógica del servidor existente, lo que le permite pasar la solicitud de GraphQL a su lógica y
obtener los datos solicitados. Esto separa a los clientes de los servidores y permite una
evolución independiente para ambos lados. (Buna, 2016, pág. 1). GraphQL es a menudo
confundido como una tecnología de base de datos el cual no lo es. Es un lenguaje de
consultas para APIs, no para base de datos. (howtographql.com, s.f., pág. Introduction).
Usaremos https://graphql.org/learn/ como guía, para demostrar los resultados que

obtendremos de las diferentes operaciones.
4.2. Historia de GraphQL
Diseñado y utilizado por Facebook desde 2012 (publicado y abierto en 2015) para sus
aplicaciones web y móviles, GraphQL fue creado para resolver los problemas de tiempos de
las APIs, especialmente con la sobrecarga. Esto fue causado por la estructura básica de las
consultas, causando una serie de solicitudes con exceso de datos. Esto es especialmente un
28
problema con las aplicaciones móviles que se usan con dispositivos y condiciones de red que
no pueden manejar grandes cantidades de datos y cargas útiles (payloads). Hoy GraphQL es
mantenido por una vasta comunidad en todo el mundo que consiste en compañías y personas.
(howtographql.com, s.f.)
Facebook necesitaba una API lo suficientemente fuerte para describir todos los datos de
Facebook y, al mismo tiempo, fácil de usar y aprender para sus desarrolladores de productos.
Las aplicaciones móviles de Facebook se volvían más complejas, lo que provocaba
problemas de rendimiento y fallas. El suministro de noticias se había entregado como HTML
y se veía que era necesaria una versión API de sus datos. Facebook probo RESTful como
servidor de recursos y tablas FQL para resolver sus problemas, pero se sintieron frustrados
con la diferencia de datos utilizados en las aplicaciones y en las consultas del servidor.
Querían un gráfico de objetos con modelos usados como JSON en lugar de URL de recursos,
claves secundarias y unión de tablas. También había un montón de código para el servidor al
preparar los datos y para que el cliente los analizara. (Byron, 2015)
Facebook no fue el único que busco hacer las interacciones con el API más eficientes, pero
una vez que GraphQL fue de código abierto, muchos programas como Coursera fueron
cancelados cuando ingresaron a GraphQL. (howtographql.com, s.f.)
4.3. Consultas y Resultados Precisos
La comunicación se realiza con documentos de texto en lenguaje de consulta GraphQL. Estos

documentos contienen una o varias operaciones de lectura o escritura. En GraphQL las
operaciones de lectura se llaman queries - consultas y las operaciones de escritura mutations
– mutaciones. Las consultas piden campos específicos de objetos. Un campo es como una
función, devolverá una respuesta de un valor primitivo, un objeto o una matriz de objetos. Con
estos campos, los resultados de una consulta pueden reducirse a solo los datos que se
desean. El servidor sabe exactamente lo que se le pide y el cliente recibirá lo que espera. Los
campos mapean las propiedades de los objetos. Una consulta (query) comienza con un objeto
de consulta raíz (root query object), un punto de entrada a los datos. Las consultas están
formadas por conjuntos de selección que se pueden anidar. Cada conjunto de selección se
representa con llaves, y le dicen al servidor de GraphQL que propiedades leer del campo.
(Buna, 2016, pág. 2)
Aquí se consulta un campo name de un objeto hero. El resultado de una consulta tendrá la
misma estructura que la consulta en si, como se ve en la Figura 2. No queremos recibir todos
los campos de un objeto hero, solo el name.
29
Figura 2: Consulta de GraphQL
Fuente: (graphql.org, s.f.)
4.4. Muchos recursos con una solicitud
Las consultas tienen la posibilidad de sub-selección de campos. Esto le permite al cliente

consultar los datos relacionados en una sola solicitud en lugar de muchas consultas de ida y
vuelta. También es posible agregar argumentos a los campos. Con estos argumentos, los
datos ya pueden transformarse en la forma deseada.
El sub-campo friends dará como resultado los nombres de los amigos del objeto hero.
Figura 3: Consulta GraphQL con sub-campo Friends

Un argumento “id” especifica un objeto human y un argumento unit transformará el campo height
en la forma deseada.
Figura 4: Consulta GraphQL con Argumentos

30
4.4.1. Alias
Los campos del objeto de los resultados de las consultas coinciden con los nombres de
los campos de la consulta en sí. Sin embargo, para algunos propósitos, los nombres que
usa la interfaz de usuario pueden ser diferentes de los del servidor. En GraphQL, cualquier
nombre de campo se puede personalizar con alias. Estos alias deben ser descriptivos
para la consulta en particular o para el propósito de uso en la Interfaz de Usuario. La
consulta seguirá solicitando los mismos datos, pero la declaración utilizará los nombres
especificados en las respuestas. Por lo tanto, el cliente no necesitará un procesamiento
adicional de datos antes de usarlo. Los alias también permiten que se solicite el mismo
campo varias veces si es necesario. (Buna, 2016, pág. 2)
Figura 5: Consulta GraphQL con Alias

4.4.2. Fragmentación
GraphQL también permite la fragmentación en una consulta. En lugar de repetir campos,

para comparar dos conjuntos de datos, por ejemplo, es posible incluir unidades de
fragmentos reutilizables para las consultas donde se necesiten. Los subcomponentes y
las vistas múltiples pueden solicitar datos aislados sin duplicar la lógica de la consulta.
Los fragmentos no se pueden usar solos ya que son solo operaciones parciales. Deben
estar prefijados con un operador extendido (tres puntos) para ser usado dentro de una
operación completa. Cuando el servidor de GraphQL ve los tres puntos seguido de un
nombre dentro de una consulta, buscará un fragmento con el mismo nombre. El contenido
del fragmento se colocará en el operador de difusión. El fragmento debe encajar en el
lugar donde se usa y, por lo tanto, solo se puede usar dentro de la selección. (Buna, 2016,
pág. 2)
31
Figura 6: Consulta GraphQL con Fragmentos
4.4.3. Variables
Usar variables como entradas hará que las consultas de GraphQL sean dinámicas y
reutilizables. Reemplazando un valor estático en una consulta con $nombreDeVariable
seguido por su tipo, declarándolo como una variable aceptada de la consulta y pasando
un valor (nombreDeVariable: valor) en un diccionario separado para transferir variables
(generalmente JSON). Después de que la variable se define en la parte superior de la
consulta, se puede usar en cualquier lugar dentro de esa operación de la consulta. (Buna,
32
2016, pág. 2). Mismos nombres de variables pueden ser usados en diferentes
operaciones, pero tienen que ser únicos dentro de cada operación. (Buna, 2016, pág. 2).
Las variables pueden ser requeridas para una consulta utilizando el signo “!” después del
tipo ($nombreDeVariable: tipo!). Los valores predeterminados también pueden asignarse
para las consultas después de la declaración del tipo. Si se pasa una variable para la
consulta, anulara la predeterminada.
Figura 7: Consulta GraphQL con Variables

4.4.4. Directivas
El servidor de GraphQL puede personalizar la respuesta de la consulta en función de una

directiva. La respuesta puede incluir algo más (@include (if: Boolean)) u omitir algo (@skip
(if: Boolean)) en función de si la variable es verdadera o no. Esto permite que la Interfaz
de Usuario tenga una vista resumida y detallada, por ejemplo. (graphql.org, s.f.)
Figura 8: Consulta GraphQL con Directivas

33
4.4.5. Mutaciones
La actualización de datos se puede hacer con mutaciones en GraphQL y campos como

entrada de datos. Los campos de mutaciones se ejecutarán uno tras otro, en serie, a
diferencia de las consultas. Esto significa que se puede realizar muchas mutaciones en
una sola consulta, y se garantiza que el primero finaliza antes del siguiente y así
sucesivamente.
Figura 9: Consulta GraphQL con Mutaciones

4.5. El Sistema de Tipo
Aunque los resultados de las consultas GraphQL dan como resultado resultados predecibles,
se debe definir un esquema. El esquema explica las capacidades del servidor de GraphQL.
Este se puede ver como un contrato entre el cliente y el servidor que define como el cliente
podrá acceder a los datos (howtographql.com, s.f.). GraphQL tiene un sistema de tipos para
describir los datos que son posibles para consultar. Cada servicio define este conjunto de
tipos los cuales las consultas ejecutan y validan. (graphql.org, s.f., pág. Schemas and Types)
4.5.1. Tipos de Objetos
Los tipos de objetos son el núcleo de las consultas y representan que tipo de objetos se
pueden recuperar y que campos tienen. Cada uno de los campos puede tener ninguno o
más argumentos que pueden ser necesarios o no. Si un argumento es opcional, puede
tener un valor predeterminado. Todos los argumentos son pasados por un nombre y por
lo tanto tienen que ser siempre nombrados. (graphql.org, s.f., pág. Schemas and Types)
34
4.5.2. Tipos Escalares
Para que los campos resuelvan datos reales GraphQL tiene tipos escalares. Además de
los tipos escalares personalizados, existen los siguientes tipos escalares
predeterminados: (graphql.org, s.f., pág. Schemas and Types)
• Int: Un entero de 32 bits con signo.
• Float: Un valor de punto flotante de precisión doble con signo.
• String: Una secuencia de caracteres UTF-8.
• Boolean: verdadero o falso.
• ID: Un identificador único serializado.
Los valores también se pueden establecer a partir de un cierto conjunto de valores, esto
se puede hacer con un tipo de enumeración. Las listas y valores no nulos se pueden usar
en objetos externos, escalares, enums y declaraciones agregando modificadores de tipos
adicionales, el símbolo “!” para valores no nulos (non-null) y “[ ]“ para listas.
4.5.3. Tipos de Consulta y Mutaciones
Además de los tipos de objetos, cada servicio de GraphQL tendrá un tipo de consulta y
puede tener tipos de mutación. Ambos sirven como punto de entrada al esquema, pero
siguen siendo exactamente como tipos de objetos y sus campos funcionan de la misma
manera. (graphql.org, s.f., pág. Schemas and Types)
4.5.4. Tipos de Suscripción
Algunas aplicaciones pueden requerir una conexión en tiempo real al servidor para
obtener información inmediata sobre algunos eventos, esto se puede hacer con
suscripciones en GraphQL. Cuando un evento es suscrito por un cliente, se abre una
conexión estable al servidor. Cada vez que ocurre es suscrito por un cliente, se abre una
conexión estable al servidor. Cada vez que ocurre un evento, los datos se envían al cliente
desde el servidor. Esto significa que, aunque están escritos con la misma sintaxis que las
consultas y mutaciones, las suscripciones representan una secuencia de datos en lugar
de un ciclo de solicitud y respuesta. (howtographql.com, s.f., pág. Core Concepts)
4.5.5. Tipos de Interfaz y Unión
Las interfaces y las uniones son ambos tipos abstractos usados para agrupar otros tipos.
Si los tipos tienen campos comunes, la interfaz puede ser usada para devolver ese grupo
de tipos como un todo. La interfaz definirá los campos que la implementación debe
35
contener y, por lo tanto, garantiza que esos campos siempre sean compatibles con esa
interfaz. Los tipos utilizados tendrán todos los campos de la interfaz, pero también pueden
traer campos adicionales propios. Los fragmentos en línea se pueden usar para solicitar
estos campos adicionales fuera de la interfaz. (Buna, 2016, pág. 3)
Las uniones se pueden usar cuando los tipos no tienen campos comunes, pero aún así
se desean agrupar. Los tipos tienen que ser concretos, no otras uniones o fragmentos. La
unión definirá una lista de diferentes implementaciones. Los fragmentos en línea se
utilizan para solicitar los campos de los tipos representados por una unión. (graphql.org,
s.f., pág. Schemas and Types)
4.5.6. Tipos de Entrada
Los tipos de entrada tienen el mismo aspecto que los tipos de objeto en el esquema de
GraphQL, solo tiene la palabra clave “input” en lugar de “type”. Las entradas permiten
pasar objetos complejos a los campos. Esto es útil en mutaciones donde se crean nuevos
objetos. Los campos del objeto de entrada no pueden tener argumentos y no pueden
mezclarse con los tipos de salida. (graphql.org, s.f., pág. Schemas and Types)
5. REST vs. GraphQL
Aunque GraphQL a menudo se ve como un reemplazo para REST que no es necesariamente la

verdad, incluso se podrían usar uno al lado de otro. REST es un concepto arquitectónico y donde
GraphQL es un lenguaje de consulta. REST se enfoca en crear APIs de larga duración, mientras
que los puntos fuertes de GraphQL son el rendimiento y flexibilidad. REST puede utilizar tipos de
contenido HTTP, almacenamiento en cache, etc. GraphQL tiene sus propias prácticas. REST
tiene HATEOAS que no es necesariamente utilizada de todos modos.
5.1. Consultas
Tanto GraphQL como REST funcionan en torno a la idea de recursos especificados por IDs.
En REST, la identidad de un objeto, así como la forma y el tamaño se llaman en el punto final
de la consulta, mientras que en GraphQL, la identidad es independiente de la obtención y el
formato será determinado por el cliente. Ambas APIs tendrán una lista de posibles acciones
con separación de operaciones de lectura y escritura. REST tiene una lista de end-points que
comienzan con GET o POST, mientras que GraphQL tiene un esquema de consultas y
mutaciones.
Los verbos HTTP usados por REST se pueden ver más fáciles de entender para los humanos.
GET recuperará datos, DELETE eliminará. Los verbos son bastante obvios para el
consumidor. Uno sabe para qué están tabulados, que sucederá y que son seguros de usar
36
sin siquiera leer la documentación. GraphQL podría no ser tan claro. La única forma segura
de saber a qué se llama una mutación para eliminar un elemento es mirarlo desde la
documentación. Los proveedores de API tendrán sus propias formas de nombrar las
operaciones y no se garantiza que todo sea coherente incluso dentro de una misma API. El
protocolo HTTP puede proporcionar más consistencia y predictibilidad. Lo mismo ocurre con
los códigos de estado HTTP, ambos son legibles por máquina y por humanos. Al utilizar
REST, podemos saber que ocurre simplemente desde el estado de HTTP. Las consultas
GraphQL estarán “OK” incluso si la consulta no hubiera tenido éxito.
Usar métodos y respuestas HTTP trae limitaciones. REST accede a múltiples end-points para
recopilar datos. Por ejemplo, primero un punto final para buscar a un usuario, otro para
obtener todas las publicaciones de ese usuario y otro para obtener una lista de seguidores. A
menudo, los desarrolladores se ven obligados a una gran personalización e interpretación
para mantener las cargas útiles (payload) al mínimo. Sin embargo, los clientes no tendrán
ningún control sobre la personalización, a menos que tengan los derechos para hacerlo. De
lo contrario, depende del desarrollador proporcionar las consultas y respuestas necesarias.
Aun así, los dos se pueden ver como lenguajes completamente diferentes. Casi como
preguntar algo en inglés y obtener una respuesta en japonés. (Buna, 2016)
La manera de GraphQL es la menor cantidad posible de solicitudes, donde REST tendrá el

máximo rendimiento. Las consultas de GraphQL pueden invocar múltiples recursos, tener
argumentos en cualquier campo y obtener datos relacionados según las relaciones que crean
una respuesta anidada. La librería de ejecución crea la forma de las respuestas en GraphQL
para que coincida con la forma de las consultas.
5.2. Uso de la API
GraphQL se creó a partir de las necesidades de hoy, especialmente las necesidades de los
clientes móviles. Los dispositivos de baja potencia transfieren datos con redes no ideales. Los
clientes móviles necesitan potencia y capacidad para elegir que datos consumir. Las
aplicaciones móviles también evolucionan rápidamente y sus versiones no se pueden
controlar bien. Por lo tanto, GraphQL minimiza la cantidad de datos transferidos y permite
agregar nuevas características sin eliminar las antiguas. (Buna, 2016)
Múltiples diferentes Frameworks de front-end y plataformas ejecutadas por aplicaciones

cliente causan problemas al construir y mantener una sola API. Es difícil cumplir con los
requisitos de todos ellos. GraphQL puede facilitar el proceso al brindar a cada cliente acceso
a la información que ellos necesitan. (howtographql.com, s.f.)
37
GraphQL fuerza a tener consultas más eficientes y elimina muchas preguntas de diseño. Con
GraphQL, los clientes pueden escribir sus propias consultas y usar el lenguaje de su elección
en lugar de forzar a los desarrolladores a crear end-points personalizados, o APIs para
resolver problemas con diferentes clientes y sus necesidades. El lenguaje declarativo para
los requisitos de datos en GraphQL se asemeja a la forma de pensar los requisitos de datos
en ingles aliviando el trabajo de pensamiento que entra en él. (Buna, 2016)
5.3. Caché
REST puede confiar fácilmente en el almacenamiento en cache HTTP y evitar volver a buscar
los mismos datos porque está basado en end-points. Con GraphQL, el cliente debe manejar
el almacenamiento en caché. Un cliente como Relay puede proporcionar un sistema de caché.
Estos sistemas son complejos y dado que es posible que no proporcionen información sobre
cuánto tiempo son válidos los datos, actualizar la caché depende del consumidor.
Aunque GraphQL no tiene identificadores únicos a nivel global, como las URLs para cada
solicitud, los identificadores similares pueden exponerse para que los clientes los utilicen con
fines de almacenamiento en caché. Además, a medida que las solicitudes se personalizan,
es probable que se produzcan menos visitas de caché, lo que significa que REST se verá
forzado a seguir la misma ruta de manejo del almacenamiento en caché que GraphQL.
5.4. Evolución de la API
REST y GraphQL pueden versionar y evolucionar, pero las deprecaciones son el punto fuerte
de GraphQL. Dado que el uso del campo de monitoreo es fácil en GraphQL, los
desarrolladores pueden rastrear y llegar a los clientes a los que afectarán las nuevas
versiones. A diferencia de GraphQL, donde los clientes se ven obligados a especificar que
campos desean que se devuelvan, en REST saber esto es muy difícil. Esto dará como
resultado nuevas versiones completas y la anterior no se podrá descartar hasta que todos los
clientes hayan realizado el cambio, incluso si los cambios solo afectan el uso de algunos de
ellos.
Las aplicaciones tienden a tener actualizaciones frecuentes con implementación continua.

Las API REST exponen los datos de una manera en la que es muy probable que se necesiten
modificaciones cada vez que se realizan cambios de diseño en la interfaz de usuario. Las
necesidades de datos cambian y es posible que se necesiten más o menos datos para solicitar
causados por cada cambio realizado en la interfaz de usuario. Con GraphQL, los clientes
mismos especifican los requisitos de datos y los ajustes de back-end no serán necesarios
38
cuando cambien las necesidades de diseño o datos de la interfaz de usuario. El desarrollo y
las iteraciones de productos pueden ser extremadamente rápidos. (howtographql.com, s.f.)
Las API REST tienden a crearse simples al principio y luego tiene características similares al
lenguaje de consulta. GraphQL, por otro lado, proporcionará una sintaxis de lenguaje de
consulta y kits de desarrollo de software. Se pueden obtener los mismos resultados con
REST, pero sigue siendo un concepto sin reglas escritas. “Con GraphQL, los clientes y
servidores son independientes y se pueden modificar sin afectarse entre sí”. (Buna, 2016)
Con las aplicaciones web, es más fácil controlar las versiones de API simplemente subiendo
nuevo código. Las aplicaciones móviles son otra historia, ya que las versiones no se pueden
controlar fácilmente. Un usuario puede descargar una aplicación y seguir usando la versión
instalada sin actualizarla. GraphQL permite que las API crezcan sin versionar. Se pueden
agregar nuevos campos sin eliminar los antiguos, ya que el gráfico puede crecer de manera
flexible dejando rutas para las antiguas API. (Buna, 2016)
5.5. GraphQL o REST
Cual elegir GraphQL o REST? Debemos considerar las siguientes preguntas.
• ¿Qué tipos de clientes tienes y si son diferentes el uno del otro? Si la aplicación tendrá
una versión web y móvil, o incluso si solo es una aplicación móvil, las fortalezas de
GraphQL podrían ser el lugar donde basas tu decisión.
• ¿Sus clientes manejan el almacenamiento en caché? E incluso si los son, el

almacenamiento en caché será más fácil con REST.
• ¿Quieres darle poder al cliente o mantenerlo “tonto”? Con GraphQL, los clientes
estarán a cargo de una gran cantidad de tareas realizadas por el desarrollador.
• ¿Cuánto valoras los proxies HTTP de depuración y caché? Si ya tiene mucho

conocimiento de HTTP, se beneficiará con REST.
Si una API REST sigue buenas prácticas, los beneficios de GraphQL pueden ser insuficientes.
Sin embargo, si un vasto campo de clientes con diferentes necesidades requiere datos
limitados, con consultas de bajo costo, GraphQL API podría ser lo que estás buscando. Dicho
esto, en la vida real de las arquitecturas orientadas a servicios, a menudo se usan múltiples
servicios diferentes con múltiples APIs. Algunos podrían ser REST, algunos GraphQL.
39
6. Conclusiones
Se mencionó los aspectos más importantes de REST tales como que es un modelo Cliente-
Servidor, las solicitudes tienen que contener toda la información necesaria para hacer la consulta
(Stateless), las respuesta a las solicitudes deben ser almacenadas en caché, se debe establecer
una interfaz uniforme utilizando identificadores únicos, separar los componentes del sistema en
múltiples capas y por ultimo usar HATEOAS que permite al cliente interactuar completamente
con nuestra aplicación a través de enlaces de hipermedia sin conocimiento previo de como
interactuar con la aplicación, todo lo mencionado son las restricciones de REST las cuales deben
seguirse a la hora de crear un API REST bien definido.
También se mencionó los aspectos más importantes de GraphQL, es un lenguaje de consulta,

tiene una forma mucho más directa, sencilla y eficiente para obtener exactamente los datos que
se requieren utilizando una única solicitud y al ser un lenguaje de consulta puede ser utilizado en
diferentes lenguajes de programación.
Y por último también se mencionó las principales diferencias entre REST y GraphQL:
• Ambos funcionan con la idea de recursos especificados por IDs, pero REST ya tiene
definida la forma en cambio en GraphQL el formato es especificado por el cliente, dando
acceso a la información que ellos necesitan.
• Ambas APIs tendrán una lista de posibles acciones con separación de operaciones de
lectura y escritura. REST tiene una lista de end-points que comienzan con GET o POST,
mientras que GraphQL tiene un esquema de consultas y mutaciones.
• Los verbos HTTP usados por REST se pueden ver más fáciles de entender para los
humanos. GraphQL podría no ser tan claro.
• REST accede a múltiples end-points para recopilar datos. La manera de GraphQL es usar
la menor cantidad posible de solicitudes
• REST puede confiar fácilmente en el almacenamiento en caché HTTP y evitar volver a

buscar los mismos datos porque está basado en end-points. Con GraphQL, el cliente debe
manejar el almacenamiento en caché.
• REST por lo general se convierte en un laberinto de end-points mal documentados.

GraphQL es altamente tipado y auto-documentado.
Conocer estas diferencias ayudará mucho a decidir cuál de estas dos tecnologías o posiblemente
ambas, podrían ser utilizadas a la hora de crear un API.
40
7. Bibliografía
Libros:
Buna, S. (2016). Learning GraphQL and Relay. Birmingham: Packt Publishing Ltd.
Byron, L. (2015). GraphQL: A data query language. Obtenido de Facebook Code:

https://code.fb.com/core-data/graphql-a-data-query-language/
Doglio, F. (2015). Pro REST API Development with Node.js.
Jacobson, D., Brail, G., & Woods, D. (2012). APIs: A Strategy Guide. En D. Jacobson, G. Brail, &
D. Woods, APIs: A Strategy Guide (pág. 4). O'Reilly Media.
Sandoval, J. (2009). RESTful Java Web Services. Birmingham: Packt Publishing Ltd.
Uzayr, S. b. (2016). Learning Wordpress REST API. Birmingham: Packt Publishing Ltd.
Páginas Web:
graphql.org. (s.f.). graphql.org. Obtenido de graphql.org: graphql.org
howtographql.com. (s.f.). How To GraphQL. Obtenido de How To GraphQL:

https://www.howtographql.com
41

Como Desarrollar Aplicabiones Web Con API REST y GRAPHLQ

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Como Desarrollar Aplicabiones Web Con API REST y GRAPHLQ

Hochgeladen von

Copyright:

Verfügbare Formate

UNIVERSIDAD MAYOR DE SAN SIMON

FACULTAD DE CIENCIAS Y TECNOLOGIA

COMO DESARROLLAR APLICACIONES WEB

TRABAJO FINAL PRESENTADO PARA OBTENER EL CERTIFICADO

POSTULANTE : Ronal Giovanny Delgadillo Hinojosa

REST (Representational State Transfer – Transferencia de Estado Representacional) cambió por

Pero recientemente fueron observadas algunas limitaciones en el uso de REST, la necesidad de

Un API (Application Programming Interface – Interfaz de Programación de Aplicaciones) puede

El objetivo y la motivación de esta monografía es proveer una investigación de cómo desarrollar

1.1. Antecedentes Generales

1.2. Antecedentes Específicos

• Debe ser un sistema Cliente – Servidor.

• Tiene que soportar un sistema de cacheo, la infraestructura de red debe soportar

• Tiene que estar en capas, debe soportar la escalabilidad.

Ahora se hablará un poco de GraphQL. GraphQL es un lenguaje de consultas (queries)

Estos son algunas diferencias entre GraphQL y REST

• REST requiere varias consultas, GraphQL requiere solo una.

• REST por lo general se convierte en un laberinto de end-points mal documentados.

Para el presente trabajo se utilizará los siguientes métodos de investigación:

• Método Bibliográfico, debido a que se realizará la lectura y compilación de libros

• Método Analítico, debido a que se procederá a revisar y analizar ordenadamente

3. Desarrollo de Aplicaciones Web con API REST

3.2. Recursos, Representaciones y Solicitudes

• GET /api/resource?q=[TERMINO DE BUQUEDA]

• GET /api/resource?filters=[LISTA DE FILTROS SEPARADAS POR COMA]

3.3.1. Cliente - Servidor

3.3.2. Sin Estado (Stateless)

La desventaja de la restricción es la sobrecarga potencial de las solicitudes. Cuando se

3.3.4. Interfaz Uniforme

3.3.5. Sistema de Capas

HATEOAS es la abreviatura de Hypermedia as the Engine of Application State –

HATEOAS se asemeja a un proceso familiar de ingresar a una página web. El cliente

HATEOAS mejora significativamente el desacoplamiento entre el cliente y el servidor.

3.4. Establecer cómo desarrollar un servicio web con REST

El proceso de desarrollo RESTful sigue paradigmas de desarrollo tradicionales. Sin embargo,

El diseño de servicios web RESTful no es diferente del diseño de aplicaciones web

1. Recopilación de requisitos: este paso es similar a las prácticas tradicionales de

2. Identificación de recursos: Este paso es similar a DOO (Diseño Orientado a

3. Definición de Representación de Recursos: debido a que intercambiamos

4. Definición de la URI: Con los recursos implementados, necesitamos definir la API,

Al igual que con cualquier aplicación, se comenzará enumerando los principales

• Los usuarios registrados publican entradas de blog en sus cuentas. Limitamos

• Los usuarios registrados y no registrados ven los perfiles de usuario.

• Los usuarios registrados actualizan sus perfiles de usuario.

• Los usuarios registrados y no registrados buscan términos en todas las

3.4.1.2. Identificación de Recursos

(Sandoval, 2009, pág. 71)

3.4.1.3. Definición de Representación

Una representación es un mapeo temporal de un recurso en el momento de una

Un servicio web RESTful bien diseñado debe proporcionar múltiples representaciones

Llegar al formato de representación ideal es una cuestión del proceso de diseño. Se

Finalmente, se debe tener en cuenta la vinculación de las representaciones. La

3.4.1.3.1. Representaciones en XML

Del análisis, se identificarán dos tipos de recursos: usuarios y mensajes. Como

Primero se definirá una representación de usuario de la siguiente manera:

Ahora se definirá una lista de usuarios de la siguiente manera:

Esta estructura XML declara una lista de usuarios que se almacena en un

Primero se definirá una solo entrada de blog o mensaje de la siguiente manera:

Finalmente, se definirá una lista de mensajes de la siguiente manera:

Esta estructura XML contiene una colección de mensajes, y cada mensaje

Se usa los mismos nombres de clave para la representación en JSON, y aún se

Se define una representación de usuario de la siguiente manera:

Y se define una lista de usuarios de la siguiente manera: