¿Cuál es la diferencia entre OData, JsonAPI, GraphQL?

json-api

Question

He usado OData en mi carrera bastante y ahora algunos de mis colegas de diferentes equipos recomendaron que nos cambiemos a JsonAPI y GraphQL, ya que no está vinculado a Microsoft. No tengo mucha experiencia en estos dos lenguajes de consulta. Por lo que sé, OData es un estándar utilizado por Salesforce, IBM, Microsoft y está muy desarrollado. ¿Por qué debería cambiarse a JsonAPI y / o GraphQL? ¿Hay un beneficio real? ¿Es JsonAPI y GraphQL nuevo estándar? Cambiar las implementaciones de API públicas basadas en la popularidad parece inútil, especialmente cuando no hay un gran beneficio.

¿Alguien puede por favor iluminarme?

Answer 1

OData es una especificación similar a la API JSON. Ambos describen un estándar para la creación y el consumo de API RESTful. GraphQL es un nuevo enfoque para el diseño de API y especifica una forma diferente de consultar los recursos de API.

• OData : Diseñado y desarrollado en Microsoft desde 2007, estandarizado por el consorcio OASIS . La última versión V4 se envía a ISO / IEC JTC 1 para su aprobación como estándar internacional. Las compañías en el comité técnico (TC) incluyen a CA Technologies, Citrix, IBM, Microsoft, Progress, Red Hat, SAP y SDL.

  Hay una serie de bibliotecas para lenguajes de programación populares: .NET, Java, JavaScript, PHP y Ruby. La especificación permite recursos dinámicos y hay un documento de servicio que enumera todos los puntos finales de API para que los clientes los descubran. Además, hay un documento de metadatos que describe el esquema.

• API JSON : la API JSON fue redactada originalmente por Yehuda Katz en mayo de 2013. Este primer borrador se extrajo del transporte JSON definido implícitamente por el adaptador REST de Ember Data. La versión estable actual de la especificación es 1.0 . La especificación de la API de JSON se implementa para la mayoría de los lenguajes de programación, tanto para el cliente como para el servidor.

  JSON API admite HATEOAS a través de la propiedad de link en el documento JSON. Otras características incluyen paginación, clasificación, filtrado y relaciones. Los documentos JSON producidos por los servidores de API JSON son muy detallados con muchas propiedades anidadas.

• GraphQL : Desarrollado en Facebook desde 2015. La specification sigue siendo un borrador de trabajo. Es bastante popular entre los fanáticos de React y se usa principalmente en combinación con React o Vue.js. Similar a GraphQL es Falcor, que también es relativamente nuevo.

  Si bien GraphQL utiliza HTTP, no se considera REST, sino una alternativa a REST. En su lugar, utiliza un modelo de consulta / respuesta en un solo documento JSON (virtual). Este nuevo modelo es algo más agradable para que trabajen los desarrolladores, pero sus beneficios sobre REST son discutibles. Dada su corta edad, el ecosistema aún no ha madurado.

En aras de la claridad y la integridad, incluiré OpenAPI en la lista, aunque no es exactamente una especificación de API. Eso puede ser confuso para algunas personas. El estándar OpenAPI es un estándar de lenguaje independiente para describir y definir API. Su API puede seguir uno de los estándares anteriores (excluyendo GraphQL) y también puede documentarse utilizando Swagger 3, por ejemplo.

• OpenAPI (también conocido como Swagger) : Desarrollado como parte de la Iniciativa OpenAPI y la Fundación Linux. Soportado por grandes compañías tecnológicas como Google, Microsoft, IBM, SAP, Oracle, Ebay y PayPal. La versión actual de la especificación es 3.0.1 . Hay implementaciones para la mayoría de los lenguajes de programación, así como muchas herramientas adicionales como generadores de IU web, etc.

Lo mejor que obtienes con especificaciones como Swagger es la herramienta que las rodea: generadores para las páginas de documentación de la API, generadores para el código SDK del cliente, etc.

Este estándar es probablemente el más utilizado hoy en día para la documentación de API y la generación de código. También es compatible con proveedores en la nube como Amazon Web Services en su API Gateway (solo v2).

Mi opinión personal:

Como puede ver, existen bastantes especificaciones REST, más que un único estándar universal. Estoy de acuerdo con xumix aquí, todos parecen sufrir el síndrome "No hemos inventado aquí". Los beneficios de elegir cualquiera de los anteriores son pequeños, especialmente si su proyecto es de tamaño pequeño o mediano. ¿Importa qué especificación implementa tu API? Probablemente no mucho. Solo enfócate en construir una API consistente y bien documentada.