OpenAPI in Foundation

[Gionanni]

Ciao, ci troviamo a dover scambiare informazioni con sistemi esterni (tra cui GPT) che sempre più richiedono un interfaccia API al passo dei tempi.
Quando presentiamo l'interfaccia WEBAPI di foundation spesso ci nicchiano un po'.
Anche se non mi piace stavamo pensando di realizzare un'interfaccia intermedia sviluppata con framework tipo https://fastapi.tiangolo.com/ o django che venisse a consumare le WEBAPI foundation.
Avete anche voi la stessa esigenza? come affrontate la questione?

[d.pierangeli]

Interessante, OpenAPI non è uno standard che definisce il formato delle API ma è solo uno standard di descrizione di API generiche.

Quindi il problema secondo te è nella FORMA delle API scelte da noi e quindi nelle specifiche oppure che non esiste un metodo per mostrarle e consumarle in maniera facile?

[Gionanni]

Le differenze rispetto agli standard che abbiamo sempre incontrato sono:
- la possibilità di evitare l'utilizzo dell'header: X-HTTP-Method-Override per le funzioni "custom": ci piacerebbe utilizzare un endpoint del tipo https:\\api.miodominio.it\apiV1\entita\proceduracustom che prenda sul body un payload JSON/XML "liscio" senza doverlo includere in un oggetto nominato come il parametro della funzione definita in INDE
- le risposte in GET se restitiuiscono un solo valore ritornano un oggetto se restituiscono un insieme ritornano invece un array, questa "ambiguità" porta a dover fare del lavoro in più lato client per distinguere i due casi
- le risposte in GET vengono sempre racchiuse all'interno di un oggetto nominato come la classe che poi al suo interno contiene i dati. Anche questo è un comportamento diverso rispetto a quello che si incontra solitamente e porta ad avere risposte meno "pulite
- le risposte in GET includono sempre gli attributi "do_xxxx" che ci piacerebbe evitare di mandare in giro sempre per una pulizia delle risposte

Alcuni di questi "inconventi" li abbiamo superati introducendo un documentHelper che intercetta le chiamate ma non è il massimo...

[f.dellamalva]

Per l'ultimo punto, non so se è esattamente il tuo caso e può esserti utile.
Nell'evento OnSaveXMLProp della classe DO utilizzata per le risposte, azzero il TagEsterno quanto il nome della proprietà si riferisce a quelle proprietà generate da INDE in questo modo le proprietà non vengono inserite nel Json o XML della risposta.

[r.bianco]

Le differenze rispetto agli standard che abbiamo sempre incontrato sono:
- la possibilità di evitare l'utilizzo dell'header: X-HTTP-Method-Override per le funzioni "custom": ci piacerebbe utilizzare un endpoint del tipo https:\\api.miodominio.it\apiV1\entita\proceduracustom che prenda sul body un payload JSON/XML "liscio" senza doverlo includere in un oggetto nominato come il parametro della funzione definita in INDE
- le risposte in GET se restitiuiscono un solo valore ritornano un oggetto se restituiscono un insieme ritornano invece un array, questa "ambiguità" porta a dover fare del lavoro in più lato client per distinguere i due casi
- le risposte in GET vengono sempre racchiuse all'interno di un oggetto nominato come la classe che poi al suo interno contiene i dati. Anche questo è un comportamento diverso rispetto a quello che si incontra solitamente e porta ad avere risposte meno "pulite
- le risposte in GET includono sempre gli attributi "do_xxxx" che ci piacerebbe evitare di mandare in giro sempre per una pulizia delle risposte

Alcuni di questi "inconventi" li abbiamo superati introducendo un documentHelper che intercetta le chiamate ma non è il massimo...

Concordo. Finché si parla di far comunicare inde con inde è molto comodo avere il rispetto del formato "DO" anche nella risposta WebAPI. Ma quando si parla di InDe verso "altro", lascia tutti gli "altro" un po' spiazzati.
Tempo fa, se non ricordo male, mi son fatto una funzione che "pulisce" il JSON generato da InDe, prima di restituirlo al richiedente.

[d.termini]

Concordo pure io. Soprattutto nel primo punto di evitare di dover incapsulare il body in un oggetto nominato come il parametro.
Spesso me ne dimentico e poi errori su errori e non capisco cosa manca, poi vien fuori che o manca l'incapsulamento oppure il parametro è in un case diverso da quello del body (eh sì, è pure case sensitive...)

[d.pierangeli]

Questo feedback è molto interessante, l'ho portato all'attenzione.

Purtroppo non possiamo modificare molto ora per retrocompatibilità, forse si potrebbe usare l'ennesimo parametro di compilazione.

[r.bianco]

Questo feedback è molto interessante, l'ho portato all'attenzione.

Purtroppo non possiamo modificare molto ora per retrocompatibilità, forse si potrebbe usare l'ennesimo parametro di compilazione.

Forse meglio intercettare un parametro nell'header della richiesta, che indica se se si vuole una risposta che rispetta il formato DO oppure no.
E` solo un'idea.

[d.termini]

Questo feedback è molto interessante, l'ho portato all'attenzione.

Purtroppo non possiamo modificare molto ora per retrocompatibilità, forse si potrebbe usare l'ennesimo parametro di compilazione.

Forse meglio intercettare un parametro nell'header della richiesta, che indica se se si vuole una risposta che rispetta il formato DO oppure no.
E` solo un'idea.

Io lo stavo pensando come proprietà della procedura, così è il programmatore che decide e non il fruitore dell'API, nasce default "InDe" e lo si può mettere "custom" o "resto del mondo" :P Così si possono mantenere entrambe le versioni.
Per le chiamate standard (quelle DO di InDe) invece penso che la proposta di Riccardo vada bene, però nascendo di default "InDe" altrimenti si rompe la retrocompatibilità, deve essere il fruitore a decidere come la vuole.