GraphQL è molto popolare, molto potente, ma è fondamentalmente diverso da OData. Quindi non è che nessuno sia assolutamente migliore dell'altro.
Ci sono alcuni punti che posso capire.
OData = SQL in URL
OData era un modo per serializzare un'istruzione SQL in un URL
È difficile limitare la capacità di interrogare il lato client.
OData Standardizzato
La specifica di OData è la sua forza, proprio come RPC fa per RESTful. RESTful ha specifiche ed è facile da capire, ma non è facile esprimere tutto. RPC può esprimere tutto, ma è troppo poco standardizzato.
Difetti in OData
OData di solito è più preciso dello stato dello schema del database (quindi è come SQL Query), e una volta cambiato lo schema, è più difficile mantenere la vecchia versione.
OData preferisce la gestione unificata ed è difficile ottimizzarla per casi particolari.
Meglio descritto
OData è come SQL Query, GraphQL è come stored procedure. Assaggi lentamente.
Pertanto, questi due devono coesistere e completarsi a vicenda.
sommario
OData è come SQL Query, GraphQL è come stored procedure.
OData è come RESTful, e GraphQL è come RPC
Quando vuoi un'unificazione semplice, troverai RESTFul ottimo, SQL Query è sufficiente, OData è buono.
Ma quando ci si trovano situazioni particolari e non si può usare un metodo semplice, RPC, stored procedure, GraphQL ne mette in risalto il fascino.
Vediamo gli scenari di utilizzo di entrambe le parti. OData è incline a essere un'API per applicazioni aziendali, come SAP. Di solito il modello più semplice e relazionale del database.
GraphQL è un'applicazione Internet, un'API esposta e qualsiasi tipo di dato (come NoSQL)
Quindi, in sintesi, GraphQL può esprimere più (più liberamente) di OData, OData ha regole (più vincoli) rispetto a GraphQL
Quale sia, o GraphQL per il mondo esterno, o OData per l'interno, dipende davvero dal progetto per usarla.
Pubblicato su 20/05/2023 20:28:50
|
|
|
|
