[Arquitetura da Web] Qual é a diferença entre OData, JsonAPI e GraphQL?

pergunta:

Eu usei muito OData em minha carreira e agora alguns de meus colegas de equipes diferentes sugerem que mudemos para JsonAPI e GraphQL porque não tem nada a ver com a Microsoft. Não tenho muita experiência com nenhuma das linguagens de consulta. Pelo que eu sei, OData é um padrão usado pela Salesforce, IBM, Microsoft e está muito maduro. Por que mudar para JsonAPI e/ou GraphQL? Existem benefícios reais? JsonAPI e GraphQL são o novo padrão? Alterar a implementação da API pública com base na popularidade não parece funcionar, especialmente se não houver muitos benefícios.

Alguém pode me esclarecer?

Responder:

OData é uma especificação semelhante à API JSON. Ambos descrevem protocolos padrão para criar e consumir APIs RESTful. GraphQL é uma abordagem completamente diferente para design de API e especifica uma maneira diferente de consultar recursos de API.

OData:

Projetado e desenvolvido na Microsoft desde 2007, padronizado pelo consórcio OASIS. A última versão, V4, foi submetida à ISO/IEC JTC 1 para aprovação como Norma Internacional. As empresas do Comitê Técnico (TC) incluem CA Technologies, Citrix, IBM, Microsoft, Progress, Red Hat, SAP e SDL.

Existem muitas bibliotecas para linguagens de programação populares - .NET, Java, JavaScript, PHP e Ruby. A especificação permite recursos dinâmicos e há um documento de serviço listando todos os endpoints de API para os clientes descobrirem. Além disso, há um documento de metadados que descreve o esquema.

API JSON:

A API JSON foi originalmente elaborada por Yehuda Katz em maio de 2013. Este primeiro rascunho foi extraído do transporte JSON implicitamente definido pelo adaptador REST da Ember Data. A versão estável atual da especificação é 1.0. A especificação da API JSON se aplica à maioria das linguagens de programação, tanto cliente quanto servidor.

A API JSON oferece suporte a HATEOAS por meio de atributos de link em documentos JSON. Recursos adicionais incluem paginação, classificação, filtragem e relacionamentos. Os documentos JSON gerados pelos servidores JSON API são muito detalhados, com muitas propriedades aninhadas.

GraphQL:

Desenvolvido no Facebook desde 2015. A especificação ainda é um rascunho de trabalho. É popular entre os fãs do React e é usado principalmente em conjunto com React ou Vue.js. Semelhante ao GraphQL é o Falcor, que também é relativamente novo.

Embora o GraphQL use HTTP, ele não é considerado REST, mas um substituto para REST. Em vez disso, ele usa um modelo de consulta/resposta em um único documento JSON (virtual). Esse novo modelo é mais amigável ao desenvolvedor, mas suas vantagens sobre o REST são discutíveis. Dada a sua juventude, o ecossistema é imaturo.

Para maior clareza e abrangência, estou incluindo OpenAPI na lista, mesmo que não seja exatamente uma especificação de API. Isso pode confundir algumas pessoas. O padrão OpenAPI é um padrão independente de linguagem para descrever e definir APIs. Por exemplo, sua API pode seguir um dos padrões acima (excluindo GraphQL) ou pode ser documentada usando OpenAPI 3.

OpenAPI (também conhecido como Swagger):

Desenvolvido como parte da OpenAPI Initiative e da Linux Foundation. Apoiado por grandes empresas de tecnologia como Google, Microsoft, IBM, SAP, Oracle, Ebay e PayPal. A versão atual da especificação é 3.1.0. Existem implementações para a maioria das linguagens de programação, bem como muitas outras ferramentas, como Web UI Builders, etc.


A melhor coisa que você obtém com uma especificação como OpenAPI são as ferramentas em torno deles - geradores para páginas de documentação da API, geradores para código SDK do cliente, etc.

Esse padrão é provavelmente o mais usado atualmente para declarações de API, documentação e geração de código. Também é suportado por provedores de nuvem, como Amazon Web Services, em seus gateways de API.

Em resumo, OData e JSON API são formatos de dados JSON que adicionam contexto e recursos em torno dos dados (como links), GraphQL é uma nova maneira completamente diferente de consultar e modificar dados JSON e OpenAPI é uma maneira de declarar e documentar qualquer dados API RESTful do método padrão.

Minha opinião pessoal:

Como você pode ver, existem muitas especificações RESTful, em vez de um único padrão universal. Concordo com xumix - todos parecem sofrer da síndrome do "nada inventado aqui". Há pouco benefício em escolher qualquer um dos itens acima, especialmente se o seu projeto for de pequeno a médio porte. A especificação de sua implementação de API é importante? Provavelmente não muitos. Concentre-se apenas em criar APIs consistentes e bem documentadas.

Este artigo : https://architect.pub/what-difference-between-odata-jsonapi-graphql
Discussão: Knowledge Planet [Chief Architect Circle] ou adicionar trompete WeChat [ca_cto] ou adicionar grupo QQ [792862318]
Sem público
 

【jiagoushipro】
【Super Arquiteto】
Brilhante gráfico e explicação detalhada da metodologia de arquitetura, prática de arquitetura, princípios técnicos e tendências técnicas.

WeChat trompete
 
[ca_cea]
Comunidade de 50.000 pessoas, discutindo: arquitetura empresarial, computação em nuvem, big data, ciência de dados, Internet das Coisas, inteligência artificial, segurança, desenvolvimento full-stack, DevOps, digitalização.

Grupo QQ
 
[285069459] Intercâmbio aprofundado de arquitetura empresarial, arquitetura de negócios, arquitetura de aplicativos, arquitetura de dados, arquitetura técnica, arquitetura de integração, arquitetura de segurança. E várias tecnologias emergentes, como big data, computação em nuvem, Internet das Coisas, inteligência artificial, etc.

planeta do conhecimento Conheça mais amigos, local de trabalho e bate-papo técnico. Planeta do conhecimento【Local de trabalho e tecnologia】
local na rede Internet CIO (Diretor de Informação) https://cio.ceo
local na rede Internet CIOs, CTOs e CDOs https://cioctocdo.com
local na rede Internet Compartilhamento prático do arquiteto https://architect.pub   
local na rede Internet Compartilhamento de desenvolvimento de nuvem do programador https://pgmr.cloud
local na rede Internet Arquiteto Chefe Comunidade https://jiagoushi.pro
local na rede Internet bate-papo do desenvolvedor https://blog.developer.chat
local na rede Internet Cobrança CPO https://cpo.work

Obrigado pela atenção, encaminhamento, curtidas e observação.

おすすめ

転載: blog.csdn.net/jiagoushipro/article/details/131887195