Le migliori pratiche riguardanti le interfacce tra le lingue "tipizzate" e "non tipizzate"?

1

Il nostro codice JavaScript / Vue frontend fa uso di un numero di endpoint REST "interni", che sono implementati in Java usando Jersey / jax-rs.

Abbiamo una specifica "informale" che elenca le diverse operazioni di REST e descrive i "bean" che sono passati in / out. Sul lato Java, abbiamo classi bean diverse e usiamo gson per trasformare le stringhe JSON in ingresso in oggetti Java.

Ultimamente, ho capito che la nostra attuale configurazione sul lato Java ignora i campi di bean sconosciuti. Quindi, quando il lato JS fornisce un campo che gson non può mappare su un campo di una classe di bean Java, non accade nulla.

Da un lato, questo comportamento sembra conveniente, ad esempio consente al lato JS di fare questo:

  • chiamando un GET dal back-end, ricevendo un'istanza di qualche X bean
  • aggiungendo altre informazioni a quell'oggetto, per poi inviarlo come bean Y su una richiesta PUT

D'altra parte, dal punto di vista del backend tipizzato staticamente, è semplicemente sbagliato ignorare i dati in arrivo.

La mia domanda: ci sono migliori pratiche o schemi specifici che si applicano qui? Ci sono buoni argomenti tecnici per consentire sempre i campi "sconosciuti", o per proibirli sempre, e "fallire" le richieste usando campi sconosciuti?

    
posta GhostCat 13.08.2018 - 16:09
fonte

2 risposte

2

Ignorare i campi sconosciuti è una (molto importante) funzione di mantenere le API compatibili all'indietro. Questo è particolarmente importante quando le soluzioni vengono distribuite in momenti diversi. Ad esempio se il codice frontend ha la propria pipeline e il backend è in un altro o backend è suddiviso in microservices o anche se è in esecuzione un codice in cui è impossibile controllarlo (in un browser in cui l'utente ha una pagina caricata, non è possibile forzare li loro per ricaricare senza inconvenienti).

Se vuoi aggiungere un campo che si apre a un browser e farlo tornare generosamente, va qualcosa come:

  1. aggiungi un nuovo campo al back-end (e al rilascio)
  2. aggiorna il frontend per utilizzare i nuovi campi (e rilasciare)
  3. aggiorna il backend per richiedere un nuovo campo (e rilascio)

Questo aiuta a minimizzare gli errori e a consentire la suddivisione del codice in più componenti.

    
risposta data 13.09.2018 - 19:03
fonte
1

VALIDAZIONE dei messaggi

Ai vecchi tempi, ciò avveniva con WSDL. Ora, se stai usando JSON, questo è meno standardizzato, ma adeguatamente ora.

Utilizza lo schema JSON

In questo modo, quando i tuoi client inviano messaggi non conformi, gli sviluppatori riceveranno IMMEDIATAMENTE un feedback e nemmeno il codice di check-in interrotto (si spera). Invece di eseguire il debug di qualcosa di strano, giorni o settimane dopo la scrittura del codice.

    
risposta data 13.08.2018 - 16:24
fonte

Leggi altre domande sui tag