Sviluppo di SQL - REST Adapter

Question

Sviluppo di SQL - REST Adapter

#1 da (2 voti)

0

Questa è una domanda molto concettuale e alla ricerca di consigli o esempi che potresti conoscere. Sto solo tornando allo sviluppo dopo una lunga pausa in una carriera di vendita, quindi per favore scusami se i miei pensieri o domande sembrano semplicistici o obsoleti.

I dati per un numero molto elevato di implementazioni si stanno spostando fuori sito da un server SQL a cui accedere da pochissime API RESTful specifiche. Piuttosto che spendere le ore uomo per rinnovare ogni iterazione dell'accesso ai dati alle richieste REST GET, mi chiedo se c'è un modo migliore. La mia idea è di sviluppare (o trovare) un livello SQL che (invisibile al client) adatta le richieste SQL in richieste REST e restituisce i dati in formato SQL. Tutto allora, il client dovrebbe fare è passare l'origine SQL al nuovo "servizio SQL" e recuperare automaticamente i dati dall'API REST formattati per adattarsi all'applicazione.

Potrebbe non essere possibile creare un traduttore universale API REST perché gli schemi di dati sono così diversi tra JSON / XML e SQL in generale, ma mi chiedo se le API che sto accedendo utilizzino lo stesso schema di dati se qualcosa non fosse possibile essere sviluppato per la mia specifica implementazione Forse avrei bisogno di modificare questa applicazione del livello adattatore per le sfumature di ciascun cliente nelle loro query SQL, ma forse questo potrebbe risparmiare tempo di sviluppo per ogni cliente che non vuole correre alla totale riqualificazione della sua piattaforma.

Mi chiedo se una cosa del genere sia già stata compiuta prima, è persino possibile, e quali sono le questioni da affrontare. Questo è troppo di un cerotto che si romperà con i cambiamenti dei dati? Potrebbe essere abbastanza leggero da funzionare senza rallentamenti significativi? Qualsiasi consiglio o pensiero è molto apprezzato.

sql api rest

posta joeyda3rd 30.01.2018 - 19:22

fonte

1 risposta

Leggi altre domande sui tag sql api rest

Classi lavabili: dovrei mantenere solo l'id per i risultati o l'intera classe Quando utilizzare gli stub

score 2 · Answer 1

Questo non è generalmente possibile. REST e SQL hanno concetti completamente diversi.

REST riguarda le risorse e il trasferimento di stato.
SQL riguarda le query sui dati relazionali.

Tuttavia vi sono alcune sovrapposizioni: entrambe gestiscono i dati e possono gestire bene i flussi di lavoro CRUD (create-read-update-delete).

La differenza principale è che SQL consente di specificare le query in modo ad-hoc e di unirsi a più tabelle. Al contrario, REST non consente di eseguire query complesse sul datamodel. Se crei un traduttore SQL-to-REST, i risultati saranno probabilmente molto inefficienti (ad esempio, i join dovrebbero essere eseguiti lato client o forniti da una risorsa dedicata).

Un piano di migrazione ragionevole eliminerà prima questa differenza, limitando tutti i client a un insieme fisso di query preparate. Questi dovrebbero essere incapsulati in alcune librerie, ad es. usando il modello di deposito. Questo passaggio ti aiuterà anche a raccogliere i requisiti corretti per l'API REST.

Una volta che i client si sono spostati in quella libreria, sei libero di cambiare gli interni. È quindi possibile sviluppare una sostituzione con la stessa interfaccia che non utilizza query SQL ma accede ai dati tramite un'API REST. Questa libreria è quindi una sostituzione drop-in. Il server API potrebbe continuare a utilizzare il repository basato su SQL per un po 'di tempo.

Si noti che una tale migrazione è davvero difficile a meno che non si controllino tutti i client API. Se altri team o altre organizzazioni hanno creato questi client, avranno un piccolo incentivo per l'aggiornamento: non puoi semplicemente mantenere il server SQL in esecuzione per loro? Questo è quindi meno una sfida di ingegneria del software e più un problema politico. La soluzione più semplice (se si dispone del capitale politico necessario) è presentare un piano di migrazione a lungo termine in cui l'accesso SQL verrà disattivato in una certa data, con un tempo di migrazione sufficiente sufficiente. Ma c'è probabilmente un client legacy business-critical che nessuno comprende e non può essere aggiornato, quindi sarai costretto a mantenere l'accesso SQL in esecuzione per sempre, il che chiama tutta la migrazione in questione. Quindi, forse controlla prima.