Considerazioni sulla progettazione dello schema JSON per un'API

Question

Considerazioni sulla progettazione dello schema JSON per un'API

#1 da (1 voti)
#2 da (0 voti)

1

Ho un endpoint API che recupera i dati da 3 tabelle SQL sul lato server. Al momento, eseguo un SELECT con join, consolido / riorganizzo i dati selezionati in base a uno schema JSON, quindi invio JSON al client. Il punto qui è che quasi nessuno dei valori dei dati viene modificato, solo la loro struttura viene trasformata dallo schema SQL allo schema JSON.

Sul lato client, mantengo anche 3 tabelle SQL che sono molto simili a quelle sul server. Al momento, analizzo il JSON, ri-trasformo i dati e li salvo in quelle tabelle.

Mi chiedo, sul lato server, se possiamo semplicemente scaricare i dati da ciascuna delle 3 tabelle in JSON senza alcuna trasformazione, in modo che sia il server che il client possano salvare qualsiasi trasformazione / ristrutturazione, considerando le tabelle su entrambi i lati (più o meno) corrispondono nello schema.

Il vantaggio (solo?) di questa idea è ovvio, ma mi chiedo se ci sia qualche serio inconveniente. Per esempi:

Perdiamo l'astrazione dei dati sul lato server.
Facciamo affidamento sulla stretta corrispondenza tra schemi di tabelle su entrambi i lati, che probabilmente renderà più difficile in futuro modificare / aggiungere colonne a quelle tabelle su entrambi i lati.
Può essere OK per un'API interna che viene utilizzata dai client che controllo, ma probabilmente non è così eccezionale per i client / sviluppatori esterni in futuro.

Fino ad ora non riesco a trovare nulla di cui sopra, e non sono sicuro al 100% di quanto siano gravi tutti i problemi.

design api-design api json client-server

posta MLister 13.05.2015 - 20:09

fonte

2 risposte

Leggi altre domande sui tag design api-design api json client-server

La memorizzazione di dati che raramente cambia in memoria è un buon candidato per un singleton / cache? Simulazione di una linea di produzione

score 1 · Answer 1

I tuoi dati JSON dovrebbero contenere le informazioni che l'utente dell'API si aspetta. Il che dovrebbe significare soprattutto che è documentato e fornisce le informazioni documentate. Lo schema non dovrebbe dipendere dalla progettazione del tuo database. E, naturalmente, se il tuo progetto di database cambia, l'API non può cambiare. Quindi basare la tua API sulla tua attuale progettazione di database significa che dopo una modifica devi tradurre i dati esistenti in dati basati sul vecchio design del database, il che è un problema.

Ciò che ritengo sia molto utile è quando non c'è alcuna ridondanza. Perché ogni volta che ci sono informazioni ridondanti, il consumatore deve preoccuparsi di cosa fare se le informazioni ridondanti non sono coerenti.

score 0 · Answer 2

Penso che, esattamente come hai fatto notare, le grandi considerazioni sarebbero

Cosa accadrebbe se l'implementazione sul lato client o sul server dovesse cambiare.
In che modo gli sviluppatori futuri estenderanno l'API se è stata scritta in questo modo
In che modo questo design influisce sulla modularità / riutilizzabilità dell'API

Quello che stai proponendo accoppierà strettamente una parte dell'API allo schema del database, che in generale è qualcosa da evitare. Dai un'occhiata a questo keynote per API di Joshua Bloch . Uno dei principi generali è che l'implementazione non dovrebbe influire sull'API. Non è una "regola", ma a meno che tu non abbia una buona ragione per farlo, terrei l'implementazione e l'API disaccoppiata il più possibile.