Creare una descrizione del servizio Web e derivarne il codice o viceversa?

3

Ho scritto personalmente alcuni piccoli servizi HTTP e i client che li hanno consumati. C'è una domanda su CodeReview nelle domande a caldo su un wrapper per alcune API RESTful che mi ha fatto meraviglia, se mai dovessi scrivere "involucri" a mano "?

Il mio flusso di lavoro era in genere:

  1. Scrivi codice lato server
  2. Provalo o, per essere sincero, prova it
  3. Scrivi wrapper sul lato client per utilizzare il servizio

Ho sentito parlare di linguaggi che descrivono i servizi (WSDL) e che consentono la generazione automatizzata di tali wrapper. Questo ha senso: se il servizio cambia, anche i wrapper.

Non ho mai usato descrizioni di questo tipo per i servizi che ho scritto. Tuttavia, ho notato lo sforzo duplicato di scrivere codice sia su server che su client su una "interfaccia" comune. C'è anche un sacco di codice boilerplate, come fare richieste, serializzare / deserializzare i dati in JSON, XML o qualsiasi altro formato. Sarebbe bello ottenere automaticamente il codice wrapper.

Si dice che i linguaggi di descrizione devono essere scritti automaticamente, derivati da un codice di servizio già scritto.

Perché è così? Perché non dovrei avviare il processo scrivendo una descrizione del servizio, in modo da poter creare automaticamente wrapper per esso sia dal lato server che lato client? O almeno creare gli stub di classi / metodi con parametri già (de) / serializzati, ecc. Perché è necessario scrivere codice, derivarne una descrizione per ricavare codice da quello. Oppure la mia comprensione delle descrizioni dei servizi è errata? Mi piacerebbe migliorare il mio codice utilizzando le descrizioni dei servizi.

Quando avvio un nuovo progetto che non deve essere applicato a nessun codice esistente, non è la migliore idea di creare prima la descrizione, di avere una definizione astratta dell'intera cosa e ricavarne tutto il resto?

    
posta null 04.09.2016 - 01:04
fonte

1 risposta

2

I descrittori di servizio sono fondamentalmente un formato di metadati "standard" per i servizi.

Questo ci consente di creare librerie client che sanno come eseguire le operazioni di tipo standard, come endpoint per ogni risorsa, gestione CSRF, ecc.

Ciò consente al client di utilizzare un servizio su un'interfaccia "standard" (come SQL, controlla i documenti OData per vedere cosa intendo), in contrasto con i servizi web ad-hoc che possono avere qualsiasi interfaccia lo sviluppatore desideri.

Quindi WSDL, OData ecc. specificano molte cose che rendono TALKING più facile ai servizi, ma non molto su come il servizio è scritto.

Il back-end è libero di servire le richieste nel modo desiderato.

Data questa libertà per il back-end, le cose che possono essere automatizzate sono ... limitate. Esistono già cose standard come la generazione delle classi per ciascuna risorsa e la specifica di serializzatori ecc.

Generalmente la generazione di descrittori è automatizzata, quindi vedo prima l'uso limitato del file descrittore. In effetti, così facendo potresti limitare inutilmente il codice back-end.

EDIT: aggiunta di un esempio per illustrare,

Dire che la descrizione astratta del servizio dice che Groceries è una risorsa, sul client possiamo dire E implementare:

  • ottieni il primo numero x di voci per generi alimentari
  • ordina i generi alimentari
  • acquista generi alimentari e generi alimentari correlati

Sto solo dando alcuni esempi, ma ci sono un sacco di altre cose che puoi fare, controlla link

EDIT2: ho spiegato lo scenario in cui vogliamo usare infra invece di averlo generato per noi.

Ci sono alcuni approcci più recenti che effettivamente prendono il file descrittore e fanno cose interessanti con esso (generazione di codice, test automatizzati ecc.)

Ho visto un lavoro correlato alla RAML ( link ) Questa è una novità, ma forse un modo migliore. Sembra essere almeno uno più semplice:).

EDIT3: In qualche modo correlato, controlla GraphQL anche da Facebook, è legato a React. Penso che l'idea possa essere generalizzata, l'apollo di Meteor sta anche facendo un lavoro interessante su questo.

P.S OData è una specifica basata su REST per i servizi Web, leggi di più su odata.org

    
risposta data 04.09.2016 - 21:50
fonte

Leggi altre domande sui tag