Proposte per parametri custom Servizi Nazionali #15
Conversation
| - name: [Nome business function] | ||
| description: [Descrizione business function] | ||
| x-technology-type: [Da definire secondo glossario/dominio dei valori] | ||
| x-glossary: |
There was a problem hiding this comment.
Le info di glossario non le metterei direttamente qui ma in components.schemas.
Guarda in questo draft come le informazioni di glossario siano indicate sia sulla classe
che per campo.
Un parser può semplicemente ricostruire tutto il gioco leggendo lo yaml e ricavare l'informazione completa e aggiornata.
| x-audience: | ||
| visibility: [Set di valori che definiscono chi può visualizzare questa API] | ||
| allowed-profiles: [Elenco dei profili business abilitati a consumare l'API] | ||
| x-ecosystem: |
There was a problem hiding this comment.
x-ecosystem è sotto x-catalog ?
There was a problem hiding this comment.
si, faccio una pull request per apportare la modifica
| visibility: [Set di valori che definiscono chi può visualizzare questa API] | ||
| allowed-profiles: [Elenco dei profili business abilitati a consumare l'API] | ||
| x-ecosystem: | ||
| - name: [Nome ecosistema] |
There was a problem hiding this comment.
In questo caso (Muoversi Lombardia) potete valorizzare i campi? @stefkohub
| x-rating: | ||
| stats: [URL lettura statistiche KPI API] | ||
| rating: [URL lettura rating API] | ||
| x-api-id: [Identificativo univoco insieme di funzionalita'] |
There was a problem hiding this comment.
Qui ci mettiamo un bel provvisiorio 00000000-0000-0000-0000-000000000000
There was a problem hiding this comment.
Fai tu PR non devi fare merge delle mie modifiche.
| x-gdpr: | ||
| - data: [Informazione da gestire (ad es. Codice Fiscale)] | ||
| data-type: [Tipologia (ad es. personale|sensibile|giudiziario)] | ||
| x-lifecycle: |
There was a problem hiding this comment.
Possiamo prendere i valori dal file di specifica E015? Chi lo gestisce? Possiamo coinvolgerli in modo da ottenere un template che loro possono riusare.
There was a problem hiding this comment.
published: 2018-01-01 # data di pubblicazione
deprecated: 2020-12-31
retired: 2021-03-31
``` @stefkohub attendo conferma da te/lispa
| description: Sulla base del testo inserito per effettuare la ricerca, il servizio | ||
| restituisce una lista di punti, ognuno dei quali corredato da una descrizione, | ||
| una tipologia e la coppia di coordinate che ne individua la posizione. | ||
| x-lifecycle: |
There was a problem hiding this comment.
Questo se definito fa' override del default definito per l'API, corretto? Per i campi scaduti useremo deprecated https://swagger.io/specification/#operationObject.
There was a problem hiding this comment.
Sono a due livelli differenti. Può esserci l'API "Muoversi in Lombardia" con stato "stable" in generale, ma un metodo "/droneManage" in versione "alpha" ed il metodo "/carriola" in "deprecated".
There was a problem hiding this comment.
generalmente d'accordo, ma devo capire come marcare i metodi in alpha in maniera standard.
Ti faccio io un commento per domani
| x-publisher: [dati publisher] | ||
| x-provider: [dati provider servizi] | ||
| x-complexity-index: [valore della complessità delle api (in FP)] | ||
| x-gdpr: |
There was a problem hiding this comment.
Questo avrebbe senso gestirlo con la granularità negli schemas, in modo da poter taggare i singoli campi e appoggiarsi ad eventuali schemi metadatabili (Eg. vedi il riferimento che questo schema ha verso le ontologie https://github.com/teamdigitale/openapi/blob/master/docs/schemas/tax_code.yaml)
In questo caso si potrebbe fare anche un lavoro più articolato, collegando i singoli schemi e/o dati alle ontologie agid.
There was a problem hiding this comment.
totalmente d'accordo, va spostato negli schemas. Il parser lato server può comporre tutte le informazioni relative alla privacy scorrendo le informazioni sulla privacy dei dati che vanno trattati direttamente nella definizione dei dati stessi.
There was a problem hiding this comment.
Esatto, e le indicazioni potrebbero essere addirittura prese dall'ontologia agid: per questo è importante usare ove possibile quei riferimenti ed uniformare progressivamente i glossari.
Il gruppo che segue https://github.com/italia/daf-ontologie-vocabolari-controllati è molto ferrato. Se serve possiamo contattarli tramite slack.developers.italia.it #ontologie.
ioggstream
changed the base branch from
master
to
14-metadata-muoversi-lombardia
ioggstream
force-pushed
the
14-metadata-muoversi-lombardia
branch
from
066b019 to
acb3f89
Compare
2 participants
In questa nuova versione del file YAML proponiamo alcuni parametri personalizzati, utili a classificare ed identificare le funzionalità dei servizi esposti via API come "Muoversi in Lombardia".