Tl; versión dr

En una de las publicaciones anteriores, discutimos, en resumen, cómo es usar el GitHub API V3. Esta versión está diseñada para ser interactuada como cualquier otra API REST. Hay puntos finales para cada recurso a los que necesita acceder y/o modificar. Hay puntos finales para cada usuario, cada organización, cada repositorio, etc. Por ejemplo, cada usuario tiene su punto final API en https: // API.github.com/ usuarios/ Puede intentar sustituir su nombre de usuario en lugar de e ingresar la URL en un navegador para ver con qué responde la API.

Github API V4, por otro lado, usa GraphQL donde el QL significa lenguaje de consulta. GraphQL es una nueva forma de diseñar sus API. Al igual que se ofrecen muchos servicios web como API REST, no solo los que ofrecen GitHub, hay muchos servicios web que le permiten interactuar con ellos a través de GraphQL.

La diferencia más marcada que notará entre GraphQL y REST API es que GraphQL puede funcionar con un solo punto final de la API. En el caso de GitHub API V4, este punto final es https: // API.github.com/graphql y eso es eso. No tiene que preocuparse por agregar cadenas largas al final de un URI raíz o proporcionar un parámetro de cadena de consulta para obtener información adicional. Simplemente envíe un argumento como JSON a esta API, pidiendo solo las cosas que necesita, y obtendrá una carga útil JSON con la misma información que solicitó. No tiene que lidiar con la filtración de informaciones no deseadas, o sufrir gastos generales de rendimiento debido a grandes respuestas.

¿Qué es REST API??

Bueno, REST significa Representational State Transfer y API significa interfaz de programación de aplicaciones. Una API REST, o una API 'Restful', se ha convertido en la filosofía de diseño central detrás de la mayoría de las aplicaciones modernas de cliente cliente. La idea surge de la necesidad de segregar varios componentes de una aplicación como la interfaz de usuario del lado del cliente y la lógica del lado del servidor.

Entonces, la sesión entre un cliente y un servidor es típicamente estatoso. Una vez que se cargan la página web y los scripts relacionados, puede continuar interactuando con ellos y cuando realiza una acción (como presionar un botón de envío), se envía una solicitud de envío junto con toda la información contextual que el servidor web necesita procesar esa solicitud ( como nombre de usuario, fichas, etc.). La aplicación pasa de un estado a otro, pero sin una necesidad constante de conexión entre el cliente y el servidor.

REST define un conjunto de restricciones entre el cliente y el servidor, y la comunicación solo puede ocurrir bajo esas restricciones. Por ejemplo, REST sobre HTTP generalmente usa el modelo CRUD, que significa Crear, leer, actualizar y eliminar métodos HTTP como POST, GET, PUT, PUT y DELETE Ayuda a realizar esas operaciones y esas operaciones solo. Las viejas técnicas de intrusión como las inyecciones de SQL no son una posibilidad con algo así como una API REST muy escrita (aunque su descanso no es una panacea de seguridad).

También ayuda a los desarrolladores de la interfaz de usuario bastante! Dado que todo lo que recibe de una solicitud HTTP es un flujo de texto (formateado como JSON, a veces) puede implementar fácilmente una página web para navegadores o una aplicación (en su idioma preferido) sin preocuparse por la arquitectura del lado del servidor. Lee la documentación de la API para servicios como Reddit, Twitter o Facebook y puede escribir extensiones para ellos o clientes de terceros en el idioma de su elección, ya que tiene garantizado que el comportamiento de la API seguirá siendo el mismo.

Por el contrario, al servidor no le importa si el front-end está escrito en GO, Ruby o Python. Si se trata de un navegador, aplicación o una CLI. Simplemente 've' la solicitud y responde adecuadamente.

¿Qué es GraphQL??

Como con cualquier cosa en el mundo de las computadoras, las API de REST se hicieron más grandes y complejas y al mismo tiempo que la gente quería implementarlas y consumirlas de una manera más rápida y simple. Es por eso que a Facebook se le ocurrió la idea de GraphQL, y luego Open lo obtuvo. El QL en GraphQL significa lenguaje de consulta.

GraphQL permite a los clientes realizar solicitudes de API muy específicas, en lugar de realizar llamadas de API rígidas con parámetros y respuestas predefinidas. Es mucho más simple porque el servidor luego responde con los datos que le pidió, sin nada en exceso.

Eche un vistazo a esta solicitud de descanso y su respuesta correspondiente. Esta solicitud está destinada a ver solo la biografía pública de un usuario.

Solicitud: Obtenga https: // API.github.com/usuarios/
Respuesta:

"Iniciar sesión": "Octocat",
"ID": 583231,
"node_id": "mdq6vxnlcju4mzizmq ==",
"Avatar_url": "https: // avatars3.githubusercontent.com/u/583231?V = 4 ",
"gravatar_id": "",
"URL": "https: // API.github.com/usuarios/octocat ",
"html_url": "https: // github.com/octocat ",
"seguidores_url": "https: // API.github.com/usuarios/octocat/seguidores ",
"Siguiendo_url": "https: // API.github.com/users/octocat/siguientes /otro_user ",
"gists_url": "https: // API.github.com/users/octocat/gists /gist_id ",
"Stared_url": "https: // API.github.com/users/octocat/stared /propietario /repo ",
"Subscriptions_url": "https: // API.github.com/usuarios/octocat/suscripciones ",
"Organizations_url": "https: // API.github.com/usuarios/octocat/orgs ",
"repos_url": "https: // API.github.com/usuarios/octocat/repos ",
"Events_url": "https: // API.github.com/users/octocat/events /privacy ",
"Recibe_events_url": "https: // API.github.com/users/octocat/recibido_events ",
"Tipo": "Usuario",
"Site_admin": falso,
"Nombre": "The Octocat",
"Compañía": "Github",
"Blog": "http: // www.github.com/blog ",
"Ubicación": "San Francisco",
"Correo electrónico": NULL,
"Hirable": NULL,
"Bio": NULL,
"public_repos": 8,
"Public_gists": 8,
"seguidores": 2455,
"Siguiendo": 9,
"Create_at": "2011-01-25T18: 44: 36z",
"Actualated_at": "2018-11-22T16: 00: 23z"

He usado el nombre de usuario Octocat, pero puede reemplazarlo con el nombre de usuario de su elección y usar curl para hacer esta solicitud en la línea de comandos o postman si necesita una GUI. Si bien la solicitud fue simple, piense en toda la información adicional que obtiene de esta respuesta. Si tuviera que procesar datos de un millón de usuarios de estos y filtrar todos los datos innecesarios utilizando, entonces eso no es eficiente. Estás desperdiciando el ancho de banda, la memoria y la calculadora para obtener, almacenar y filtrar todos los millones de pares de valores de llave adicionales que nunca tú nunca

Además, la estructura de la respuesta no es algo que sepa de antemano. Esta respuesta JSON es equivalente al objeto del diccionario en Python, o un objeto en JavaScript. Otros puntos finales responderán con objetos JSON que pueden estar compuestos de objetos anidados, una lista anidada dentro del objeto o cualquier combinación arbitraria de tipos de datos JSON, y deberá referir la documentación para obtener los detalles. Cuando está procesando la solicitud, debe ser consciente de este formato que cambia de punto final a punto final.

GraphQL no se basa en verbos HTTP como POST, GET, PUT y Elimine para realizar operaciones CRUD en el servidor. En cambio, solo hay un tipo de tipo de solicitud HTTP y Endopint para todas las operaciones relacionadas con Crud. En el caso de GitHub, esto implica solicitudes de Tipo Post con solo un punto final https: // API.github.com/graphql

Siendo una solicitud de publicación, puede llevar consigo un cuerpo de texto como JSON a través del cual habrá nuestras operaciones GraphQL. Estas operaciones pueden ser de Typea consulta Si todo lo que quiere hacer es leer información, o puede ser un mutación En caso de que los datos deben modificarse.

Para hacer llamadas de API GraphQL, puede usar GitHub's GraphQL Explorer. Eche un vistazo a este GraphQL consulta Para obtener el mismo tipo de datos (la biografía pública de un usuario) que lo hicimos anteriormente usando REST.

Solicitud: publicar https: // API.github.com/graphql
consulta
Usuario (Iniciar sesión: "Ranvo")
biografía


Respuesta:

"datos":
"Usuario":
"bio": "entusiastas de la tecnología y la ciencia. Estoy en todo tipo de cosas no relacionadas de
Servidores a la física cuántica.\ r \ nocasionalmente, escribo publicaciones de blog sobre los intereses anteriores."

Como puede ver, la respuesta consiste solo en lo que pidió, esa es la biografía del usuario. Selecciona un usuario específico pasando el nombre de usuario (en mi caso, es ranvo) y luego solicita el valor de un atributo de ese usuario, en este caso ese atributo es biografía. El servidor API busca la información específica exacta y responde con eso y nada más.

Por otro lado, GraphQL también le permite hacer una sola solicitud y extraer información que le hubiera recibido múltiples solicitudes en la API REST tradicional. Recuerde que todas las solicitudes GraphQL están hechas en un solo punto final de la API. Tome, por ejemplo, el caso de uso en el que necesita pedirle al servidor de la API de GitHub la biografía del usuario y una de sus claves SSH. Requeriría dos resastas GET.

Solicitudes de descanso: obtener https: // API.github.com//
Obtener https: // API.github.com//llaves
Solicitud de GraphQL: publicar https: // API.github.com/graphql/
consulta
Usuario (Iniciar sesión: "Ranvo")
biografía
PublicKeys (último: 1)
bordes
nodo
llave





Respuesta GraphQL:

"datos":
"Usuario":
"bio": "entusiastas de la tecnología y la ciencia. Estoy en todo tipo de cosas no relacionadas de
Servidores a la física cuántica.\ r \ nocasionalmente, escribo publicaciones de blog sobre los intereses anteriores.",
"PublicKeys":
"Bordes": [

"nodo":
"Clave": "SSH-ED25519 AAAAC3NZAC1LZDI1NTE5AAAAIH31MVJRYDZEH8OD8JVAFPRUIGL65SWILYKPEGBUNGOT


]

Hay objetos anidados, pero si observa su solicitud, se coinciden con su solicitud para que pueda conocer y, en cierto sentido, dar forma a la estructura de la respuesta que recibe .

Conclusión

GraphQL viene con su propia curva de aprendizaje, que es muy empinada, o no empinada, dependiendo de quién sea que esté preguntando. Desde un punto de vista objetivo, puedo sentar los siguientes hechos para ti. Es flexible como ha visto anteriormente, es introspectivo; es decir, puede consultar la API GraphQL sobre la API en sí misma. Incluso si no va a construir su servidor API lo usa, es probable que tenga que interactuar con una API que solo permita GraphQL.

Puede aprender un poco más sobre sus tecnicismos aquí y si desea realizar llamadas de API GraphQL de su estación de trabajo local, use Graphiql.