Cosa c'è di meglio per una libreria client: codice userland o file schema?

Question

Cosa c'è di meglio per una libreria client: codice userland o file schema?

#1 da (1 voti)

3

Sto costruendo una libreria client che utilizza una raccolta di servizi API OpenStack. So che con il passare del tempo verranno aggiunti altri servizi, quindi voglio creare un modo pulito e pulito di strutturare la mia libreria client per ridurre al minimo i tempi di sviluppo (per futuri nuovi servizi) ed evitare la duplicazione.

Finora ho pensato a due soluzioni:

Implementa il codice userland da zero. Ogni servizio utilizza un client HTTP sottostante e per ogni operazione API esiste un metodo concreto in una classe concreta che incapsula la logica. Questa è la tua applicazione standard in cui tutto esiste in codice concreto. I vantaggi sono che è semplice ed evidente per i nuovi contributori; svantaggi è che la scrittura del codice è lenta e c'è il rischio di duplicare il codice di codice.
Implementa un qualche tipo di livello di descrizione del servizio - simile a WADLs ma più leggero e scritto in JSON. Ogni documento descrittivo agirebbe in modo analogo a API Discovery di Google in cui le risorse dell'API sono definite utilizzando JSON Schemas ; Le operazioni HTTP sono definite con tutti i loro parametri, URI, tipi di verbo, codici di stato attesi, ecc .; anche l'autenticazione è definita. I vantaggi sono che richiede meno tempo per scrivere, evita la duplicazione e forma un contratto esplicito utile per la documentazione dell'utente finale. Gli svantaggi sono che è abbastanza meta-come e difficile da capire per i nuovi arrivati.

Esistono numerose librerie client popolari che utilizzano questo tipo di schema schema, ma sto cercando di valutare i suoi aspetti positivi e negativi. Sono propenso a utilizzare gli schemi perché penso che faranno risparmiare tempo sviluppando ed evitando duplicazioni. Anche le API di OpenStack si stanno muovendo verso lo schema json.

Ci sono motivi validi per cui affidarsi agli schemi è una cattiva idea per una libreria client e / o perché il codice userland è un approccio migliore?

api schema client

posta hohner 25.04.2014 - 12:44

fonte

1 risposta

Leggi altre domande sui tag api schema client

Quali tecniche ci sono per il debug degli errori lato client remoto? C #: simula l'allocazione della memoria PostScript

score 1 · Answer 1

Dato il modo in cui la domanda è formulata, ovviamente non può esserci la risposta corretta, ma stai chiedendo pro e contro. Qui sostengo solo il codice concreto.

Il mio primo argomento contro lo schema arriva come una domanda: perché non WADL? Lo vuoi più leggero e in JSON! Sei sicuro di sapere dove tagliare il peso su WADL senza poi sapere che hai perso alcuni punti? Perché JSON e non XML? La differenza è superficiale La mia impressione è che tu pensi che WADL non sia il modo giusto per fare queste cose e pensi che i suoi problemi siano il peso e l'XML, ma potrebbero essere più profondi. Datti tu stesso una buona argomentazione: "difficile da capire per i nuovi arrivati". Ciò significa che i tuoi colleghi non potranno dare una mano a breve e non lo capirai più dopo averlo lasciato da solo per sei mesi --- lo chiamerei "difficile da mantenere".

La progettazione della lingua è difficile : sei in grado di progettare un linguaggio formale per descrivere i servizi a cui desideri collegare. Ottenere un linguaggio formale giusto è un compito difficile, come si può vedere dal modo in cui tutti i linguaggi di programmazione inizialmente hanno i loro capricci e si evolvono nel tempo. Ci sono buone probabilità che il tuo primo progetto sia, beh, non ottimale.

Il rischio di duplicazione del codice secondo me non è un argomento contro il codice concreto. Invece di investire in prima fila nella descrizione del servizio onnicomprensivo, perché non investire un po 'di tempo costantemente nel refactoring. Solo dopo aver codificato alcuni servizi saprai dove si trova realmente il codice boilerplate che puoi calcolare nella tua libreria di supporto. Col passare del tempo, questa libreria di supporto potrebbe fare per te ciò che la tua descrizione del servizio è destinata a fare --- e meglio: accelerare lo sviluppo di ulteriori servizi.

Spring potrebbe essere una specie di contro argomento. Quando hanno iniziato, molti codici sono migrati da Java in file XML e sono stati chiamati configuration . Quello che avevano in realtà era una sorta di linguaggio di programmazione interpretato e non tipizzato basato sulla sintassi XML, incluso lo svantaggio che il codice frena nella produzione invece che nel compilatore. Poi qualche tempo fa il nuovo clamore era che Spring ora può fare a meno di XML.

Jetty e Tomcat sono esempi simili e suppongo che Spring sia stato ispirato dalla configurazione XML delle applicazioni Java Servlet. Ma alla fine Tomcat è uscito con una versione "embedded" in cui l'applicazione servlet può essere costruita in puro Java, senza necessità di configurazione XML esterna, tutto il codice concreto. E Jetty sembra aver iniziato con un codice concreto solo per Java come obiettivo di design.

Bottom line: prima di spostare la logica fuori dal tuo codice e in una lingua di descrizione fatta in casa, pensaci due volte, poi pensaci su, poi vai prima con il codice concreto .-)

Sarebbe interessante sentire dopo un anno come sono andate le cose.