Il problema fondamentale qui è che REST non è uno standard. È uno stile architettonico per le API web. Sebbene esistano meccanismi per rendere queste API autodescrittive e esistono formati di descrizione dei servizi Web, la maggior parte delle API non utilizza queste tecniche e perché dovrebbero? È un sacco di cerimonie aziendali con un valore molto basso.
Anche se puoi rappresentare la struttura dell'API, devi ancora assegnare un significato ai dati che stai ricevendo. Non è davvero qualcosa che un computer può capire da solo. Ti consigliamo di guardare l'API che stai adattando e di scrivere la mappatura da solo.
La buona notizia è che questa mappatura dai dati ricevuti al datamodel del cliente può essere spesso abbastanza semplice, al punto che potresti essere in grado di specificarlo in un file di configurazione. Questo è ancora un tipo di programmazione, però. Soprattutto, queste configurazioni devono essere testate molto accuratamente per evitare la perdita di dati e il danneggiamento dei dati.
Se le API e la tua datamodel sono tutte basate su XML, puoi usare XSLT per specificare la maggior parte di queste trasformazioni. Sono sicuro che esiste una tecnologia di trasformazione simile per JSON, ma sarebbe molto più semplice effettuare la trasformazione in JavaScript.
Poiché non esiste una soluzione valida per tutti questi problemi, non sorprende che non abbia trovato alcun prodotto esistente adatto. Questo è un caso classico in cui lo sviluppo di software personalizzato è inevitabile. La cosa divertente è che è probabilmente più economico e più veloce scrivere solo un adattatore per API (e riutilizzare le parti comuni mentre il team di sviluppo rileva le somiglianze tra le API), piuttosto che sviluppare un adattatore generico che può occuparsi di qualsiasi cosa Tali progetti vaghi e complicati comportano un rischio significativamente maggiore e potrebbero non fornire mai alcun valore.
Quali opzioni ti offre? Idealmente, sarai in grado di convincere il cliente a scartare questo sogno di un adattatore universale API. Puoi provare a vestire gli adattatori separati come una "piattaforma integrata" che può essere estesa a nuove API con codice di configurazione "minimo". È possibile scrivere un adattatore generico in grado di gestire i tipi di API attualmente necessari, ma sarebbe necessario ulteriore sviluppo se sono necessari altri tipi. Questo è probabilmente un buon compromesso. Ma qualunque cosa tu faccia, non entrare in un contratto a prezzo fisso per sviluppare quel driver utopico universale - che esisterà sempre e solo nella fantasia del tuo cliente.