API Design: Expose XML o oggetti

Question

Stiamo intraprendere un nuovo servizio di livello intermedio che permetterà sistemi client interni per creare e aggiornare i record e query in alcuni negozi di dati sottostanti. Il servizio aggregherà ben 3 datastores sottostanti separati. Ai fini di questa domanda assumere:

I dati immagazzinano # 1: Proprietario del database XML
. archivio dati # 2: Off the database relazionale mensola
. archivio dati # 3:. archivio file piatto (file memorizzati in formato binario)

I clienti non sapranno (e l'assistenza), che datastore sono l'interrogazione / udpating. Il nuovo servizio sarà prendere questa decisione. La mia domanda è questa: Se la mia API XML o esporre oggetti? Per esempio. La nuova API avrà un metodo add. Partendo dal presupposto che il nostro sistema è un sistema di storage auto, allora il metodo Add della API può apparire come questo:

AddNewCar( CarObject car )

o, potrebbe assomigliare a questo:

AddNewCar( string carXml )

Ora, anche se il secondo metodo è debolmente tipizzato al momento dell'ingresso, XML sarà immediatamente convalidato contro lo schema come minimo.

Il nuovo servizio sta per essere scritto in C # (non ancora deciso su quale versione, ma probabilmente 3 / 3.5 con WCF). I clienti delle API potrebbe essere C # / VBA / VB.Net / C ++ / Java).

Le eventuali ulteriori dettagli per favore fatemelo sapere. Grazie

---

Aggiornamento: Si noti che l'API sarà anche la pubblicazione di XML su un autobus messaggio. Per esempio. quando si aggiunge una nuova vettura XML macchina verrà pubblicato in modo che chiunque sia interessato a nuove auto sarà notificata.

Answer 1

Direi che espone un'API oggetto. Anche se non per i motivi di cui sopra in un altro post -. Quello di esporre XML risultante in un formato fisso che è più difficile da cambiare

Probabilmente, un'API di oggetti di business fortemente tipizzato è così difficile cambiare in formato XML - entrambi saranno richiedono una nuova compilazione e ri-costruzione. Quindi, non è questo il motivo per cui si dovrebbe scartare XML.

La ragione - IMNSHO - è quello del livello di astrazione. A livello di API, si sta parlando in termini di ciò che oggetti o servizi business possono eseguire azioni quali da quali altri oggetti di business. Pertanto, l'API deve parlare in termini di oggetti di business.

Come già detto in un altro post qui già, è sempre possibile eseguire gli oggetti di business con rappresentazioni XML. Mantenere le rappresentazioni XML dei vostri oggetti e servizi di business ad un livello inferiore di astrazione che il vostro API vi fornirà tutta la flessibilità di XML, mentre allo stesso tempo, che consente di costruire un API di livello superiore che ha buone semantica.

Answer 2

Si consiglia di non esporre l'XML come questo risolve il formato e le decisioni future che si può affrontare per quanto riguarda le infrastrutture. Vorrei sempre andare via fortemente tipizzato per garantire correttamente estratto l'implementazione di distanza dal loro utilizzo.

Se si prende il percorso XML e scoprire, in parte attraverso lo sviluppo, che l'XML deve cambiare per qualche motivo, sarà molto più difficile cambiare tutti gli usi del vostro API per correggere il problema che se fortemente tipizzati l'API e nascose dettaglio XML dietro gli oggetti.

Answer 3

È necessario creare l'API utilizzando oggetti e leva WCF per fornire un'API XML, se necessario.

Answer 4

Si dovrebbe creare un'API utilizzando oggetti, e quindi creare un'interfaccia di servizio Web intorno a quel API (ad esempio, per Java si usa Java2WSDL sulla vostra interfaccia, e poi WSDL2Java per creare un'implementazione implementazione scheletro sul lato server o client-side , sono sicuro che una metodologia equivalente esiste in WCF) che tutti gli altri sistemi possono interrogare.

Come si dispone di client multi-lingua, credo che un servizio web è la scelta migliore, e (ignorando l'implementazione della logica di business) si trova a pochi minuti di lavoro in cima alla vostra API. È possibile distribuire i file WSDL o XSD a tutti gli sviluppatori del software client, che possono poi utilizzare per interfacciarsi con il sistema semplice e rapido.

Answer 5

Certamente l'approccio stongly digitato sarà più semplice dal punto di vista dell'utente finale-sviluppatore che è quello che preferisco. Tuttavia, se in ultima analisi, tutto viene convertito in XML dietro le quinte o siete incerti wich avvicinano i vostri clienti avranno, mi piacerebbe sicuramente consiglio di supportare sia.