Informazioni di riferimento sullo schema di configurazione di Generatore API dati

Articolo
07/10/2024

Il motore del generatore di API dati richiede un file di configurazione. Il file di configurazione di Generatore API dati offre un approccio strutturato e completo per configurare l'API, illustrando in dettaglio tutti gli elementi, dalle variabili di ambiente alle configurazioni specifiche dell'entità. Questo documento in formato JSON inizia con una proprietà $schema. Questa configurazione convalida il documento.

Le proprietà database-type e connection-string garantire una perfetta integrazione con i sistemi di database, dal database SQL di Azure all'API NoSQL di Cosmos DB.

Il file di configurazione può includere opzioni come:

Informazioni di connessione e servizio di database
Opzioni di configurazione globali e di runtime
Set di entità esposte
Metodo di autenticazione
Regole di sicurezza necessarie per accedere alle identità
Regole di mapping dei nomi tra API e database
Relazioni tra entità che non possono essere dedotti
Funzionalità univoche per servizi di database specifici

Panoramica della sintassi

Ecco una rapida suddivisione delle "sezioni" primarie in un file di configurazione.

{
  "$schema": "...",
  "data-source": { ... },
  "data-source-files": [ ... ],
  "runtime": {
    "rest": { ... },
    "graphql": { .. },
    "host": { ... },
    "cache": { ... },
    "telemetry": { ... },
    "pagination": { ... }
  }
  "entities": [ ... ]
}

Proprietà di primo livello

Ecco la descrizione delle proprietà di primo livello in un formato di tabella:

Proprietà	Descrizione
$schema	Specifica lo schema JSON per la convalida, assicurando che la configurazione sia conforme al formato richiesto.
origine dati	Contiene i dettagli sul tipo di database e sulla stringa di connessione , necessario per stabilire la connessione al database.
file di origine dati	Matrice facoltativa che specifica altri file di configurazione che potrebbero definire altre origini dati.
di runtime	Configura i comportamenti e le impostazioni di runtime, incluse le sottoproprietà per REST, GraphQL, host, cachee telemetria.
entità	Definisce il set di entità (tabelle di database, viste e così via) esposte tramite l'API, inclusi i mapping , le autorizzazioni e le relazioni .

Configurazione di esempio

Ecco un file di configurazione di esempio che include solo le proprietà necessarie per una singola entità semplice. Questo esempio è progettato per illustrare uno scenario minimo.

{
  "$schema": "https://github.com/Azure/data-api-builder/releases/latest/download/dab.draft.schema.json",
  "data-source": {
    "database-type": "mssql",
    "connection-string": "@env('sql-connection-string')"
  },
  "entities": {
    "Book": {
      "source": "dbo.books",
      "permissions": [{
          "actions": ["*"],
          "role": "anonymous"
      }]
    }
  }
}

Per un esempio di scenario più complesso, vedere la configurazione di esempio end-to-end .

Ambienti

Il file di configurazione del generatore di API dati può supportare scenari in cui è necessario supportare più ambienti, in modo analogo al file di appSettings.json in ASP.NET Core. Il framework fornisce tre valori di ambiente comuni ; Development, Staginge Production; ma è possibile scegliere di usare qualsiasi valore di ambiente scelto. L'ambiente usato dal generatore di API dati deve essere configurato usando la variabile di ambiente DAB_ENVIRONMENT.

Si consideri un esempio in cui si vuole una configurazione di base e una configurazione specifica dello sviluppo. Questo esempio richiede due file di configurazione:

	Ambiente
dab-config.json	Base
dab-config.Development.json	Sviluppo

Per usare la configurazione specifica dello sviluppo, è necessario impostare la variabile di ambiente DAB_ENVIRONMENT su Development.

I file di configurazione specifici dell'ambiente sostituiscono i valori delle proprietà nel file di configurazione di base. In questo esempio, se il valore connection-string è impostato in entrambi i file, viene usato il valore del file *.Development.json.

Fare riferimento a questa matrice per comprendere meglio quale valore viene usato a seconda della posizione in cui tale valore viene specificato (o non specificato) in entrambi i file.

	specificato nella configurazione di base	Non specificato nella configurazione di base
specificato nella configurazione dell'ambiente corrente	Ambiente corrente	Ambiente corrente
Non specificato nella configurazione dell'ambiente corrente	Base	Nessuno

Per un esempio di uso di più file di configurazione, vedere usare Generatore API dati con ambienti.

Proprietà di configurazione

Questa sezione include tutte le possibili proprietà di configurazione disponibili per un file di configurazione.

Schema

OBBLIGATORIO: ✔️ Sì

Ogni file di configurazione inizia con una proprietà , specificando il dello schema JSON per la convalida.

Formato

{
  "$schema": "<string>"
}

Esempi

I file di schema sono disponibili per le versioni 0.3.7-alpha successive in URL specifici, assicurandosi di usare la versione corretta o lo schema disponibile più recente.

https://github.com/Azure/data-api-builder/releases/download/<VERSION>-<suffix>/dab.draft.schema.json

Sostituire VERSION-suffix con la versione desiderata.

https://github.com/Azure/data-api-builder/releases/download/v0.3.7-alpha/dab.draft.schema.json

La versione più recente dello schema è sempre disponibile in https://github.com/Azure/data-api-builder/releases/latest/download/dab.draft.schema.json.

Ecco alcuni esempi di valori di schema validi.

Versione	URI	Descrizione
0.3.7-alpha	`https://github.com/Azure/data-api-builder/releases/download/v0.3.7-alpha/dab.draft.schema.json`	Usa lo schema di configurazione da una versione alfa dello strumento.
0.10.23	`https://github.com/Azure/data-api-builder/releases/download/v0.10.23/dab.draft.schema.json`	Usa lo schema di configurazione per una versione stabile dello strumento.
Ultimissimo	`https://github.com/Azure/data-api-builder/releases/latest/download/dab.draft.schema.json`	Usa la versione più recente dello schema di configurazione.

Nota

Le versioni del generatore di API dati precedenti a 0.3.7-alpha possono avere un URI dello schema diverso.

Origine dati

OBBLIGATORIO: ✔️ Sì

La sezione data-source definisce il database e l'accesso al database tramite la stringa di connessione. Definisce anche le opzioni di database. La proprietà data-source configura le credenziali necessarie per connettersi al database di backup. La sezione data-source descrive la connettività del database back-end, specificando sia il database-type che connection-string.

Formato

{
  "data-source": {
    "database-type": "...",
    "connection-string": "your-connection-string",
    
    // mssql-only
    "options": {
      "set-session-context": <true> (default) | <false>
    },
    
    // cosmosdb_nosql-only
    "options": {
      "database": "your-cosmosdb-database-name", 
      "container": "your-cosmosdb-container-name",
      "schema": "path-to-your-graphql-schema-file"
    }
  }
}

Proprietà

	Obbligatorio	Digitare
`database-type`	✔️ Sì	stringa enumerazione
`connection-string`	✔️ Sì	corda
`options`	❌ No	oggetto

Tipo di database

OBBLIGATORIO: ✔️ Sì

Stringa enumerazione utilizzata per specificare il tipo di database da utilizzare come origine dati.

Formato

{
  "data-source"{
    "database-type": "<enum-string>"
  }
}

Valori

La proprietà type indica il tipo di database back-end.

Digitare	Descrizione	Versione minima
`mssql`	Azure SQL Database	n/a
`mssql`	Istanza gestita di SQL di Azure	n/a
`mssql`	SQL Server	SQL 2016
`sqldw`	Azure SQL Data Warehouse	n/a
`postgresql`	PostgreSQL	v11
`mysql`	MySQL	v8
`cosmosdb_nosql`	Azure Cosmos DB per NoSQL	n/a
`cosmosdb_postgresql`	Azure Cosmos DB per PostgreSQL	n/a

Stringa di connessione

OBBLIGATORIO: ✔️ Sì

Stringa valore contenente una stringa di connessione valida per connettersi al servizio di database di destinazione. Stringa di connessione ADO.NET per connettersi al database back-end. Per altre informazioni, vedere ADO.NET stringhe di connessione.

Formato

{
  "data-source"{
    "connection-string": "<string>"
  }
}

Resilienza della connessione

Il generatore di API dati ritenta automaticamente le richieste di database dopo aver rilevato errori temporanei. La logica di ripetizione dei tentativi segue una strategia backoff esponenziale in cui il numero massimo di tentativi è cinque. Durata del backoff dei tentativi dopo che le richieste successive vengono calcolate usando questa formula (presupponendo che il tentativo di ripetizione corrente sia r):

$r^2$

Usando questa formula, è possibile calcolare il tempo per ogni tentativo di ripetizione in secondi.

	Secondi
first	`2`
secondo	`4`
terzo	`8`
quarto	`16`
quinto	`32`

SQL di Azure e SQL Server

Il generatore di API dati usa la libreria SqlClient per connettersi ad Azure SQL o SQL Server usando la stringa di connessione specificata nel file di configurazione. Un elenco di tutte le opzioni della stringa di connessione supportate è disponibile qui: Proprietà SqlConnection.ConnectionString.

Il generatore di API dati può anche connettersi al database di destinazione usando identità del servizio gestito.DATA BUILDER can also connect to the target database using Managed Service Identities (MSI). Il DefaultAzureCredential definito nella libreria Azure.Identity viene usato per connettersi usando identità note quando non si specifica un nome utente o una password nella stringa di connessione. Per altre informazioni, vedere DefaultAzureCredential esempi.

Esempi

Il valore usato per la stringa di connessione dipende in gran parte dal servizio di database usato nello scenario. È sempre possibile scegliere di archiviare la stringa di connessione in una variabile di ambiente e accedervi usando la funzione @env().

	Valore	Descrizione
Usare il valore stringa del database SQL di Azure	`Server=<server-address>;Database=<name-of-database>;User ID=<username>;Password=<password>;`	Stringa di connessione a un account del database SQL di Azure. Per altre informazioni, vedere stringhe di connessione del database SQL di Azure.
Usare il valore stringa di Database di Azure per PostgreSQL	`Server=<server-address>;Database=<name-of-database>;Port=5432;User Id=<username>;Password=<password>;Ssl Mode=Require;`	Stringa di connessione a un account di Database di Azure per PostgreSQL. Per altre informazioni, vedere stringhe di connessione di Database di Azure per PostgreSQL.
Usare il valore della stringa Azure Cosmos DB per NoSQL	`AccountEndpoint=<endpoint>;AccountKey=<key>;`	Stringa di connessione a un account Azure Cosmos DB per NoSQL. Per altre informazioni, vedere stringhe di connessione di Azure Cosmos DB per NoSQL.
Usare il valore stringa di Database di Azure per MySQL	`Server=<server-address>;Database=<name-of-database>;User ID=<username>;Password=<password>;Sslmode=Required;SslCa=<path-to-certificate>;`	Stringa di connessione a un account di Database di Azure per MySQL. Per altre informazioni, vedere stringhe di connessione di Database di Azure per MySQL.
della variabile di ambiente Access	`@env('database-connection-string')`	Accedere a una variabile di ambiente dal computer locale. In questo esempio viene fatto riferimento alla variabile di ambiente `database-connection-string`.

Mancia

Come procedura consigliata, evitare di archiviare informazioni riservate nel file di configurazione. Quando possibile, usare @env() per fare riferimento alle variabili di ambiente. Per altre informazioni, vedere @env() funzione.

Questi esempi illustrano semplicemente come configurare ogni tipo di database. Lo scenario potrebbe essere univoco, ma questo esempio è un buon punto di partenza. Sostituire i segnaposto, ad esempio myserver, myDataBase, mylogine myPassword con i valori effettivi specifici dell'ambiente.

mssql
```
"data-source": {
  "database-type": "mssql",
  "connection-string": "$env('my-connection-string')",
  "options": {
    "set-session-context": true
  }
}
```
- formato tipico della stringa di connessione: "Server=tcp:myserver.database.windows.net,1433;Initial Catalog=myDataBase;Persist Security Info=False;User ID=mylogin;Password=myPassword;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;"
postgresql
```
"data-source": {
  "database-type": "postgresql",
  "connection-string": "$env('my-connection-string')"
}
```
- formato tipico della stringa di connessione: "Host=myserver.postgres.database.azure.com;Database=myDataBase;Username=mylogin@myserver;Password=myPassword;"
mysql
```
"data-source": {
  "database-type": "mysql",
  "connection-string": "$env('my-connection-string')"
}
```
- formato tipico della stringa di connessione: "Server=myserver.mysql.database.azure.com;Database=myDataBase;Uid=mylogin@myserver;Pwd=myPassword;"

cosmosdb_nosql

"data-source": {
  "database-type": "cosmosdb_nosql",
  "connection-string": "$env('my-connection-string')",
  "options": {
    "database": "Your_CosmosDB_Database_Name",
    "container": "Your_CosmosDB_Container_Name",
    "schema": "Path_to_Your_GraphQL_Schema_File"
  }
}

formato tipico della stringa di connessione: "AccountEndpoint=https://mycosmosdb.documents.azure.com:443/;AccountKey=myAccountKey;"

cosmosdb_postgresql
```
"data-source": {
  "database-type": "cosmosdb_postgresql",
  "connection-string": "$env('my-connection-string')"
}
```
- formato tipico della stringa di connessione: "Host=mycosmosdb.postgres.database.azure.com;Database=myDataBase;Username=mylogin@mycosmosdb;Password=myPassword;Port=5432;SSL Mode=Require;"

Nota

Le "opzioni" specificate, ad esempio database, containere schema sono specifiche dell'API NoSQL di Azure Cosmos DB anziché dell'API PostgreSQL. Per Azure Cosmos DB usando l'API PostgreSQL, le "opzioni" non includono database, containero schema come nell'installazione di NoSQL.

Opzioni

REQUIRED: ❌ No

Sezione facoltativa di parametri chiave-valore aggiuntivi per connessioni di database specifiche.

Formato

{
  "data-source"{
    "options": {
        "<key>": "<value>"
    }
  }
}

Esempi

Indica se la sezione options è obbligatoria o meno dipende in gran parte dal servizio di database in uso.

	Valore	Descrizione
Abilitare `SESSION_CONTEXT` in SQL di Azure o sql Server	`"set-session-context": false`	Per AZURE SQL e SQL Server, Il generatore di API dati può sfruttare `SESSION_CONTEXT` per inviare i metadati specificati dall'utente al database sottostante. Tali metadati sono disponibili per il generatore di API dati in virtù delle attestazioni presenti nel token di accesso. I dati `SESSION_CONTEXT` sono disponibili per il database durante la connessione al database fino a quando tale connessione non viene chiusa. Per altre informazioni, vedere contesto di sessione.

{
  "data-source"{
    "options": {
        "set-session-context": false
    }
  }
}

File di origine dati

REQUIRED: ❌ No

Questa proprietà include i nomi dei file di configurazione di runtime che fanno riferimento a database aggiuntivi.

Formato

{
  "data-source-files": ["<string-array>"]
}

Considerazioni sul file di configurazione

La proprietà data-source in ogni file di configurazione è obbligatoria.
La proprietà entities in ogni file di configurazione è obbligatoria.
Viene usata solo l'impostazione runtime file di configurazione di primo livello.
I file di configurazione a livello figlio possono anche identificare i file figlio.
I file di configurazione possono essere inseriti nelle sottocartelle desiderate.
I nomi delle entità devono essere univoci in tutti i file di configurazione.
Le relazioni tra i file di configurazione non sono supportate.

Problemi noti

Attualmente, i file di configurazione figlio sono supportati solo in GraphQL.
Attualmente, i file di configurazione figlio non supportano le variabili di ambiente.

Esempi

{
  "data-source-files": ["dab-config-two.json", "dab-config-three.json"]
}

Sottocartelle di riferimento se in uso:

{
  "data-source-files": ["myfolder/dab-config-two.json"]
}

Runtime

REQUIRED: ❌ No

La sezione runtime descrive le opzioni che influisce sul comportamento di runtime e le impostazioni per tutte le entità esposte.

Formato

{
  "runtime": {
    "rest": {
      "path": "/api" (default),
      "enabled": <true> (default) | <false>,
      "request-body-strict": <true> (default) | <false>
    },
    "graphql": {
      "path": "/graphql" (default),
      "enabled": <true> (default) | <false>,
      "allow-introspection": <true> (default) | <false>
    },
    "host": {
      "mode": "production" (default) | "development",
      "cors": {
        "origins": ["<array-of-strings>"],
        "allow-credentials": <true> | <false> (default)
      },
      "authentication": {
        "provider": "StaticWebApps" (default) | ...,
        "jwt": {
          "audience": "<client-id>",
          "issuer": "<issuer-url>"
        }
      }
    }
  },
  "cache": {
    "enabled": <true> | <false> (default),
    "ttl-seconds": <integer; default: 5>
  },
  "pagination": {
    "max-page-size": -1, <integer; default: 100000>,
    "default-page-size": -1 | <integer; default: 100>
  },
  "telemetry": {
    "application-insights": {
      "connection-string": "<connection-string>",
      "enabled": <true> | <false> (default)
    }
  }
}

Proprietà

	Obbligatorio	Digitare
`rest`	❌ No	oggetto
`graphql`	❌ No	oggetto
`host`	❌ No	oggetto
`cache`	❌ No	oggetto

Esempi

Di seguito è riportato un esempio di sezione di runtime con più parametri predefiniti comuni specificati.

{
  "runtime": {
    "rest": {
      "enabled": true,
      "path": "/api",
      "request-body-strict": true
    },
    "graphql": {
      "enabled": true,
      "path": "/graphql",
      "allow-introspection": true
    },
    "host": {
      "mode": "development",
      "cors": {
        "allow-credentials": false,
        "origins": [
          "*"
        ]
      },
      "authentication": {
        "provider": "StaticWebApps",
        "jwt": {
          "audience": "<client-id>",
          "issuer": "<identity-provider-issuer-uri>"
        }
      }
    },
    "cache": {
      "enabled": true,
      "ttl-seconds": 5
    },
    "pagination": {
      "max-page-size": 100000,
      "default-page-size": 100
    },
    "telemetry": {
      "application-insights": {
        "connection-string": "<connection-string>",
        "enabled": true
      }
    }
  }
}

GraphQL (runtime)

REQUIRED: ❌ No

Questo oggetto definisce se GraphQL è abilitato e il nome[s] usato per esporre l'entità come tipo GraphQL. Questo oggetto è facoltativo e viene usato solo se il nome o le impostazioni predefinite non sono sufficienti. Questa sezione descrive le impostazioni globali per l'endpoint GraphQL.

Formato

{
  "runtime": {
    "graphql": {
      "path": "/graphql" (default),
      "enabled": <true> (default) | <false>,
      "allow-introspection": <true> (default) | <false>
      "multiple-mutations": <object>
    }
  }
}

Proprietà

	Obbligatorio	Digitare
`enabled`	❌ No	booleano
`path`	❌ No	corda
`allow-introspection`	❌ No	booleano
`multiple-mutations`	❌ No	oggetto

Abilitato (runtime GraphQL)

REQUIRED: ❌ No

Definisce se abilitare o disabilitare gli endpoint GraphQL a livello globale. Se disabilitato a livello globale, nessuna entità sarà accessibile tramite richieste GraphQL indipendentemente dalle singole impostazioni dell'entità.

Formato

{
  "runtime": {
    "graphql": {
      "enabled": "<boolean>"
    }
  }
}

Esempi

In questo esempio l'endpoint GraphQL è disabilitato per tutte le entità.

{
  "runtime": {
    "graphql": {
      "enabled": false
    }
  }
}

Percorso (runtime GraphQL)

REQUIRED: ❌ No

Definisce il percorso URL in cui viene reso disponibile l'endpoint GraphQL. Ad esempio, se questo parametro è impostato su /graphql, l'endpoint GraphQL viene esposto come /graphql. Per impostazione predefinita, il percorso è /graphql.

Importante

I percorsi secondari non sono consentiti per questa proprietà. Un valore di percorso personalizzato per l'endpoint GraphQL non è attualmente disponibile.

Formato

{
  "runtime": {
    "graphql": {
      "path": "<string>"
    }
  }
}

Esempi

In questo esempio, l'URI GraphQL radice è /query.

{
  "runtime": {
    "graphql": {
      "path": "/query"
    }
  }
}

Consenti introspezione (runtime GraphQL)

REQUIRED: ❌ No

Questo flag booleano controlla la possibilità di eseguire query di introspezione dello schema nell'endpoint GraphQL. L'abilitazione dell'introspezione consente ai client di eseguire query sullo schema per ottenere informazioni sui tipi di dati disponibili, sui tipi di query che possono eseguire e sulle mutazioni disponibili.

Questa funzionalità è utile durante lo sviluppo per comprendere la struttura dell'API GraphQL e per gli strumenti che generano automaticamente query. Tuttavia, per gli ambienti di produzione, potrebbe essere disabilitato per nascondere i dettagli dello schema dell'API e migliorare la sicurezza. Per impostazione predefinita, l'introspezione è abilitata, consentendo un'esplorazione immediata e completa dello schema GraphQL.

Formato

{
  "runtime": {
    "graphql": {
      "allow-introspection": "<boolean>"
    }
  }
}

Esempi

In questo esempio l'introspezione è disabilitata.

{
  "runtime": {
    "graphql": {
      "allow-introspection": false
    }
  }
}

Mutazioni multiple (runtime GraphQL)

REQUIRED: ❌ No

Configura tutte le operazioni di mutazione multiple per il runtime GraphQL.

Nota

Per impostazione predefinita, più mutazioni non sono abilitate e devono essere configurate in modo esplicito per l'abilitazione.

Formato

{
  "runtime": {
    "graphql": {
      "multiple-mutations": {
        "create": <object>
      }
    }
  }
}

Proprietà

	Obbligatorio	Digitare
`create`	❌ No	oggetto

Mutazioni multiple : creazione (runtime GraphQL)

REQUIRED: ❌ No

Configura più operazioni di creazione per il runtime GraphQL.

Formato

{
  "runtime": {
    "graphql": {
      "multiple-mutations": {
        "create": {
          "enabled": <false> (default) | <true>
        }
      }
    }
  }
}

Proprietà

	Obbligatorio	Digitare
`enabled`	✔️ Sì	booleano

Esempi

In questo esempio sono abilitate più mutazioni per il runtime GraphQL. In particolare, l'operazione di creazione multipla è abilitata specificando un valore di true per la proprietà runtime.graphql.multiple-mutations.create.enabled.

{
  "runtime": {
    "graphql": {
      "multiple-mutations": {
        "create": {
          "enabled": true
        }
      }
    }
  }
}

REST (runtime)

REQUIRED: ❌ No

Questa sezione descrive le impostazioni globali per gli endpoint REST. Queste impostazioni fungono da impostazioni predefinite per tutte le entità, ma possono essere sostituite in base alle rispettive configurazioni.

Formato

{
  "runtime": {
    "rest": {
      "path": "/api" (default),
      "enabled": <true> (default) | <false>,
      "request-body-strict": <true> (default) | <false>
    },
    ...
  }
}

Proprietà

	Obbligatorio	Digitare
`enabled`	❌ No	booleano
`path`	❌ No	corda
`request-body-strict`	❌ No	booleano

Abilitato (runtime REST)

REQUIRED: ❌ No

Flag booleano che determina la disponibilità globale degli endpoint REST. Se disabilitata, le entità non possono essere accessibili tramite REST, indipendentemente dalle singole impostazioni dell'entità.

Formato

{
  "runtime": {
    "rest": {
      "enabled": "<boolean>"
    }
  }
}

Esempi

In questo esempio l'endpoint DELL'API REST è disabilitato per tutte le entità.

{
  "runtime": {
    "rest": {
      "enabled": false
    }
  }
}

Percorso (runtime REST)

REQUIRED: ❌ No

Imposta il percorso URL per l'accesso a tutti gli endpoint REST esposti. Ad esempio, l'impostazione di path su /api rende l'endpoint REST accessibile in /api/<entity>. Non sono consentiti percorsi secondari. Questo campo è facoltativo, con /api come impostazione predefinita.

Nota

Quando si distribuisce Generatore API dati usando App Web statiche (anteprima), il servizio di Azure inserisce automaticamente il sottopercorso aggiuntivo /data-api all'URL. Questo comportamento garantisce la compatibilità con le funzionalità di App Web statiche esistenti. L'endpoint risultante sarà /data-api/api/<entity>. Questo è rilevante solo per le app Web statiche.

Importante

I percorsi secondari non sono consentiti per questa proprietà.

Formato

{
  "runtime": {
    "rest": {
      "path": "<string>"
    }
  }
}

Esempi

In questo esempio l'URI dell'API REST radice è /data.

{
  "runtime": {
    "rest": {
      "path": "/data"
    }
  }
}

Mancia

Se si definisce un'entità Author, l'endpoint per questa entità sarà /data/Author.

Corpo della richiesta strict (runtime REST)

REQUIRED: ❌ No

Questo flag booleano determina se il corpo della richiesta per un'operazione di mutazione REST può contenere campi estranei. Per impostazione predefinita, il valore è true, ovvero i campi aggiuntivi nel corpo della richiesta generano un'eccezione BadRequest. Tuttavia, l'impostazione di questo flag su false consente agli utenti di includere campi aggiuntivi nel corpo della richiesta, che vengono ignorati. È importante notare che questo flag non influisce sulle richieste DI QUERY REST (GET), perché il corpo della richiesta viene sempre ignorato per le operazioni GET.

Nota

Questo flag non influisce sulle richieste HTTP GET all'endpoint dell'API REST. Il corpo della richiesta viene sempre ignorato per le operazioni GET.

Formato

{
  "runtime": {
    "rest": {
      "request-body-strict": "<boolean>"
    }
  }
}

Esempi

In questo esempio, la convalida rigorosa del corpo della richiesta è disabilitata.

{
  "runtime": {
    "rest": {
      "request-body-strict": false
    }
  }
}

Host (runtime)

REQUIRED: ❌ No

La sezione host all'interno della configurazione di runtime fornisce impostazioni fondamentali per l'ambiente operativo del generatore di API dati. Queste impostazioni includono modalità operative, configurazione CORS e dettagli di autenticazione.

Formato

{
  "runtime": {
    ...
    "host": {
      "mode": "production" (default) | "development",
      "cors": {
        "origins": ["<array-of-strings>"],
        "allow-credentials": <true> | <false> (default)
      },
      "authentication": {
        "provider": "StaticWebApps" (default) | ...,
        "jwt": {
          "audience": "<client-id>",
          "issuer": "<issuer-url>"
        }
      }
    }
  }
  ...
}

Proprietà

	Obbligatorio	Digitare
`mode`	❌ No	stringa enumerazione
`cors`	❌ No	oggetto
`authentication`	❌ No	oggetto

Esempi

Ecco un esempio di runtime configurato per l'hosting di sviluppo.

{
  "runtime": {
    "host": {
      "mode": "development",
      "cors": {
        "allow-credentials": false,
        "origins": ["*"]
      },
      "authentication": {
        "provider": "Simulator"
      }
    }
  }
}

Modalità (runtime host)

REQUIRED: ❌ No

Definisce se il motore di Generatore API dati deve essere eseguito in modalità development o production. Il valore predefinito è production.

In genere, gli errori del database sottostanti vengono esposti in dettaglio impostando il livello predefinito di dettaglio per i log su Debug durante l'esecuzione nello sviluppo. Nell'ambiente di produzione, il livello di dettaglio per i log è impostato su Error.

Mancia

È possibile eseguire l'override del livello di log predefinito usando dab start --LogLevel <level-of-detail>. Per altre informazioni, vedere riferimento dell'interfaccia della riga di comando (CLI).

Formato

{
  "runtime": {
    "host": {
      "mode": "<enum-string>"
    }
  }
}

Valori

Ecco un elenco di valori consentiti per questa proprietà:

	Descrizione
`production`	Usare quando si ospita nell'ambiente di produzione in Azure
`development`	Uso nello sviluppo nel computer locale

CORS (runtime host)

REQUIRED: ❌ No

Impostazioni CORS (Cross-Origin Resource Sharing) per l'host del motore del generatore di API dati.

Formato

{
  "runtime": {
    "host": {
      "cors": "<object>"
    }
  }
}

Proprietà

	Obbligatorio	Digitare
`allow-credentials`	❌ No	booleano
`origins`	❌ No	matrice di stringhe

Consenti credenziali (runtime host)

REQUIRED: ❌ No

Se true, imposta l'intestazione CORS Access-Control-Allow-Credentials. Per impostazione predefinita, il valore è false.

Nota

Per altre informazioni sull'intestazione CORS Access-Control-Allow-Credentials, vedere riferimento CORS della documentazione Web MDN.

Formato

{
  "runtime": {
    "host": {
      "cors": {
        "allow-credentials": "<boolean>",
      }
    }
  }
}

Origini (runtime host)

REQUIRED: ❌ No

Imposta una matrice con un elenco di origini consentite per CORS. Questa impostazione consente il carattere jolly * per tutte le origini.

Formato

{
  "runtime": {
    "host": {
      "cors": {
        "origins": ["<string-array>"]
      }
    }
  }
}

Esempi

Ecco un esempio di host che consente CORS senza credenziali da tutte le origini.

{
  "runtime": {
    "host": {
      "cors": {
        "allow-credentials": false,
        "origins": ["*"]
      }
    }
  }
}

Autenticazione (runtime host)

REQUIRED: ❌ No

Configura l'autenticazione per l'host del generatore di API dati.

Formato

{
  "runtime": {
    "host": {
      "authentication": {
        "provider": "<enum-string>",
        "jwt": "<object>"
      }
    }
  }
}

Proprietà

	Obbligatorio	Digitare
`provider`	❌ No	stringa enumerazione
`jwt`	❌ No	oggetto

Provider (runtime host)

REQUIRED: ❌ No

L'impostazione authentication.provider all'interno della configurazione host definisce il metodo di autenticazione usato dal generatore di API dati. Determina il modo in cui l'API convalida l'identità degli utenti o dei servizi che tenta di accedere alle risorse. Questa impostazione consente flessibilità nella distribuzione e nell'integrazione supportando vari meccanismi di autenticazione personalizzati in base a diversi ambienti e requisiti di sicurezza.

Provider	Descrizione
`StaticWebApps` (impostazione predefinita)	Indica al generatore di API dati di cercare un set di intestazioni HTTP presenti solo durante l'esecuzione in un ambiente app Web statiche.
`AppService`	Quando il runtime è ospitato in Azure AppService con l'autenticazione appservice abilitata e configurata (EasyAuth).
`AzureAd`	Microsoft Entra Identity deve essere configurato in modo che possa autenticare una richiesta inviata a Generatore API dati (l'app server). Per altre informazioni, vedere autenticazione di Microsoft Entra ID.
`Simulator`	Provider di autenticazione configurabile che indica al motore di Generatore API dati di considerare tutte le richieste come autenticate. Per altre informazioni, vedere 'autenticazione locale.

Formato

{
  "runtime": {
    "host": {
      "authentication": {
        "provider": "<enum-string>",
      }
    }
  }
}

Valori

Ecco un elenco di valori consentiti per questa proprietà:

	Descrizione
`StaticWebApps`	App Web statiche di Azure
`AppService`	Servizio app di Azure
`AzureAD`	Microsoft Entra ID
`Simulator`	Simulatore

Token Web JSON (runtime host)

REQUIRED: ❌ No

Se il provider di autenticazione è impostato su AzureAD (ID Microsoft Entra), questa sezione è necessaria per specificare il gruppo di destinatari e le autorità emittenti per il token JWT (JSOn Web Tokens). Questi dati vengono usati per convalidare i token rispetto al tenant di Microsoft Entra.

Obbligatorio se il provider di autenticazione è AzureAD per Microsoft Entra ID. Questa sezione deve specificare il audience e issuer per convalidare il token JWT ricevuto rispetto al tenant AzureAD previsto per l'autenticazione.

Impostazione	Descrizione
pubblico	Identifica il destinatario previsto del token; in genere l'identificatore dell'applicazione registrato in Microsoft Entra Identity (o nel provider di identità), assicurandosi che il token sia stato effettivamente emesso per l'applicazione.
Emittente	Specifica l'URL dell'autorità emittente, ovvero il servizio token che ha emesso il token JWT. Questo URL deve corrispondere all'URL dell'autorità di certificazione del provider di identità da cui è stato ottenuto il token JWT, convalidando l'origine del token.

Formato

{
  "runtime": {
    "host": {
      "authentication": {
        "jwt": {
          "audience": "<string>",
          "issuer": "<string>"
        }
      }
    }
  }
}

Proprietà

	Obbligatorio	Digitare
`audience`	❌ No	corda
`issuer`	❌ No	corda

Esempi

Data API Builder (DAB) offre supporto flessibile per l'autenticazione, integrazione con Microsoft Entra Identity e server JWT (JSON Web Token) personalizzati. In questa immagine, il server JWT rappresenta il servizio di autenticazione che rilascia i token JWT ai client al termine dell'accesso. Il client passa quindi il token a DAB, che può interrogare le attestazioni e le proprietà.

Diagramma del supporto dei token Web JSON in Generatore API dati.

Di seguito sono riportati esempi della proprietà host in base alle varie opzioni di architettura che è possibile effettuare nella soluzione.

App Web statiche di Azure

{
 "host": {
  "mode": "development",
  "cors": {
   "origins": ["https://dev.example.com"],
   "credentials": true
  },
  "authentication": {
   "provider": "StaticWebApps"
  }
 }
}

Con StaticWebApps, Il generatore di API dati prevede che App Web statiche di Azure eseguano l'autenticazione della richiesta e che sia presente l'intestazione HTTP X-MS-CLIENT-PRINCIPAL.

Servizio app di Azure

{
 "host": {
  "mode": "production",
  "cors": {
   "origins": [ "https://api.example.com" ],
   "credentials": false
  },
  "authentication": {
   "provider": "AppService",
   "jwt": {
    "audience": "9e7d452b-7e23-4300-8053-55fbf243b673",
    "issuer": "https://example-appservice-auth.com"
   }
  }
 }
}

L'autenticazione viene delegata a un provider di identità supportato in cui è possibile emettere il token di accesso. Un token di accesso acquisito deve essere incluso con le richieste in ingresso a Generatore API dati. Il generatore di API dati convalida quindi tutti i token di accesso presentati, assicurandosi che il generatore di API dati fosse il pubblico previsto del token.

Microsoft Entra ID

{
 "host": {
  "mode": "production",
  "cors": {
   "origins": [ "https://api.example.com" ],
   "credentials": true
  },
  "authentication": {
   "provider": "AzureAD",
   "jwt": {
    "audience": "c123d456-a789-0abc-a12b-3c4d56e78f90",
    "issuer": "https://login.microsoftonline.com/98765f43-21ba-400c-a5de-1f2a3d4e5f6a/v2.0"
   }
  }
 }
}

Simulatore (solo sviluppo)

{
 "host": {
  "mode": "development",
  "authentication": {
   "provider": "Simulator"
  }
 }
}

Destinatari (runtime host)

REQUIRED: ❌ No

Destinatari per il token JWT.

Formato

{
  "runtime": {
    "host": {
      "authentication": {
        "jwt": {
          "audience": "<string>",
        }
      }
    }
  }
}

Autorità di certificazione (runtime host)

REQUIRED: ❌ No

Autorità di certificazione per il token JWT.

Formato

{
  "runtime": {
    "host": {
      "authentication": {
        "jwt": {
          "issuer": "<string>"
        }
      }
    }
  }
}

Paginazione (runtime)

REQUIRED: ❌ No

Configura i limiti dei risultati.

Formato

{
  "runtime": {
    "pagination": {
      "max-page-size": -1, 
      "default-page-size": -1 
    }
  }
}

Proprietà

	Obbligatorio	Digitare	Default
`max-page-size`	❌ No	numero intero	100,000
`default-page-size`	❌ No	numero intero	100

Esempio

{
  "runtime": {
    "pagination": {
      "max-page-size": 100000,
      "default-page-size": 1
    }
  }
}

Esempio di paginazione REST

Nell'esempio, se è stato emesso rest GET https://localhost:5001/api/books, il codice JSON risultante includerà un record nella matrice value perché le dimensioni della pagina sono state predefinite pari a 1. I risultati dell'esempio mostrano in che modo Generatore API dati aggiunge nextLink ai risultati quando esiste una pagina successiva.

{
  "value": [
    {
      "id": 1000,
      "title": "Prelude to Foundation",
      "year": 1988,
      "pages": 403,
      "series_id": 10000
    }
  ],
  "nextLink": "https://localhost:5001/api/books?$after=W3siRW50aXR5TmFtZSI6ImJvb2tzIiwiRmllbGROYW1lI=="
}

Si noti che l'opzione $after viene aggiunta allo stesso URL usato per eseguire query sull'endpoint. Questo valore speciale indica internamente l'ultimo record nella pagina corrente. L'utilizzo della stringa specificata come valore di $after restituirà automaticamente la pagina successiva dei dati.

Nota

È possibile che i dati della tabella sottostanti siano stati modificati tra le query. Questo non genererà un errore; Tuttavia, illustra perché Il generatore di API dati non ha il concetto di numero di pagina. Le chiamate successive restituiscono la pagina successiva corretta, ma il numero di pagina potrebbe essere stato modificato a causa di modifiche ai dati. In questo modo, il nextLink è letteralmente la pagina successiva di dati, non la pagina successiva numero.

Esempio di paginazione graphQL

Nell'esempio, se si esegue una query GraphQL, è necessario includere hasNextPage e endCursor per usare la paginazione. Il motivo di questo requisito è che gli endpoint REST determinano la struttura dei payload, ma la query del consumer determina la struttura dei payload GraphQL. Con o senza questi valori, i risultati sono ancora limitati alle dimensioni predefinite della pagina. Una query sarà simile alla seguente:

query {
  books {
    items {
      id,
      title,
      year,
      pages,
      series_id
    }
    hasNextPage
    endCursor
  }
}

I risultati di GraphQL includono hasNextPage e endCursor, usati per recuperare altre pagine.

{
  "data": {
    "books": {
      "items": [
        {
          "id": 1000,
          "title": "Prelude to Foundation",
          "year": 1988,
          "pages": 403,
          "series_id": 10000
        }
      ],
      "hasNextPage": true,
      "endCursor": "W3siRW50aXR5TmFtZSI6ImJvb2tzIiwiRmllbGROYW1lI=="
    }
  }
}

La query GraphQL successiva include il cursore come valore della variabile after nel modo seguente:

query {
  books(after: "W3siRW50aXR5TmFtZSI6ImJvb2tzIiwiRmllbGROYW1lI==") {
    items {
      id
      title
      year
      pages
      series_id
    }
    hasNextPage
    endCursor
  }
}

Uso di $limit o first per modificare le dimensioni della pagina.

Sia REST che GraphQL possono includere rispettivamente una variabile $limit o first. Lo scopo di limit è limitare i risultati per una query specifica. Si consideri tuttavia https://{server}/api/books?$limit=10. Se limit è, ad esempio, 10 quando la dimensione predefinita della pagina è 100, i risultati sono limitati a 10. Tuttavia, se limit è 200 quando le dimensioni predefinite della pagina sono pari a 100, i risultati sono limitati a 200, ovvero un valore maggiore delle dimensioni predefinite della pagina.

Primo valore	Risultato
`-1`	Valore corrente dell'impostazione `max-page-size`. L'uso di `-1` è utile quando il valore dell'impostazione `max-page-size` è sconosciuto al consumer. Generatore API dati sostituisce `-1` con il valore corrente di `max-page-size`.
`< max-page-size`	I risultati sono limitati al valore fornito.
`0`	Non valido. Viene restituita un'eccezione.
`< -1`	Non valido. Viene restituita un'eccezione.
`> max-page-size`	Non valido. Viene restituita un'eccezione.

Dimensioni massime della pagina (runtime di paginazione)

REQUIRED: ❌ No

Imposta il numero massimo di record di primo livello restituiti da una query REST o GraphQL.

Valori consentiti

Valore	Risultato
`-1`	Questo valore viene impostato per impostazione predefinita sul valore massimo supportato.
`integer`	È supportato qualsiasi numero intero positivo a 32 bit.
`< -1`	Questo non è supportato.
`= 0`	Questo non è supportato.

Nota

Il valore massimo di un intero a 32 bit è 2.147.483.647. Questo è grande. In pratica, non esiste un limite universale rigoroso alle dimensioni di un payload dell'endpoint in uscita, ma diversi fattori possono limitare efficacemente le dimensioni, tra cui la configurazione del server, la larghezza di banda e il timeout. Il generatore di API dati non conosce lo scenario, quindi questa impostazione è aperta alla configurazione da ogni sviluppatore. Il valore massimo predefinito di 100.000 è già abbastanza aggressivo.

Dimensioni di pagina predefinite (runtime di paginazione)

REQUIRED: ❌ No

Imposta le dimensioni della pagina quando la paginazione è il numero di record di primo livello restituiti da una query REST o GraphQL.

Valori consentiti

Valore	Risultato
`-1`	Per impostazione predefinita, questo valore corrisponde all'impostazione corrente del `max-page-size`.
`integer`	Qualsiasi numero intero positivo minore dell'impostazione `max-page-size` corrente.
`< -1`	Questo non è supportato.
`= 0`	Questo non è supportato.

Cache (runtime)

REQUIRED: ❌ No

Abilita e configura la memorizzazione nella cache per l'intero runtime.

Formato

{
  "runtime": {
    "cache": "<object>"
  }
}

Proprietà

	Obbligatorio	Digitare
`enabled`	❌ No	booleano
`ttl-seconds`	❌ No	numero intero

Esempi

In questo esempio la cache è abilitata e gli elementi scadono dopo 30 secondi.

{
  "runtime": {
    "cache": {
      "enabled": true,
      "ttl-seconds": 30
    }
  }
}

Abilitato (runtime della cache)

REQUIRED: ❌ No

Abilita la memorizzazione nella cache a livello globale per tutte le entità. Il valore predefinito è false.

Formato

{
  "runtime": {
    "cache":  {
      "enabled": "<boolean>"
    }
  }
}

Esempi

In questo esempio la cache è disabilitata.

{
  "runtime": {
    "cache": {
      "enabled": false
    }
  }
}

TTL in secondi (runtime della cache)

REQUIRED: ❌ No

Configura il valore TTL (Time-to-Live) in secondi per gli elementi memorizzati nella cache. Dopo questo intervallo di tempo, gli elementi vengono eliminati automaticamente dalla cache. Il valore predefinito è 5 secondi.

Formato

{
  "runtime": {
    "cache":  {
        "ttl-seconds": "<integer>"
    }
  }
}

Esempi

In questo esempio la cache è abilitata a livello globale e tutti gli elementi scadono dopo 15 secondi.

{
  "runtime": {
    "cache": {
      "enabled": true,
      "ttl-seconds": 15
    }
  }
}

Telemetria (runtime)

REQUIRED: ❌ No

Questa proprietà configura Application Insights per centralizzare i log API. Altre .

Entità

OBBLIGATORIO: ✔️ Sì

La sezione entities funge da base del file di configurazione, stabilendo un bridge tra gli oggetti di database e gli endpoint API corrispondenti. Questa sezione esegue il mapping degli oggetti di database agli endpoint esposti. Questa sezione include anche il mapping delle proprietà e la definizione delle autorizzazioni. Ogni entità esposta viene definita in un oggetto dedicato. Il nome della proprietà dell'oggetto viene usato come nome dell'entità da esporre.

Questa sezione definisce il modo in cui ogni entità nel database viene rappresentata nell'API, inclusi mapping delle proprietà e autorizzazioni. Ogni entità viene incapsulata all'interno della propria sottosezione, con il nome dell'entità che funge da chiave per riferimento in tutta la configurazione.

Formato

{
  "entities": {
    "<entity-name>": {
      "rest": {
        "enabled": <true> (default) | <false>,
        "path": "/entity-path", (default <entity-name>)
        "methods": ["GET", "POST" (default)]
      },
      "graphql": {
        "enabled": <true> (default) | <false>,
        "type": {
          "singular": "myEntity",
          "plural": "myEntities"
        },
        "operation": "query" | "mutation" (default)
      },
      "source": {
        "object": "database-object-name",
        "type": "view" | "stored-procedure" | "table",
        "key-fields": ["field-name"],
        "parameters": {
          "parameter-name": "parameter-value"
        }
      },
      "mappings": {
        "database-field-name": "field-alias"
      },
      "relationships": {
        "relationship-name": {
          "cardinality": "one" | "many",
          "target.entity": "target-entity-name",
          "source.fields": ["source-field-name"],
          "target.fields": ["target-field-name"],
          "linking.object": "linking-object-name",
          "linking.source.fields": ["linking-source-field-name"],
          "linking.target.fields": ["linking-target-field-name"]
        }
      },
      "permissions": [
        {
          "role": "anonymous | authenticated | custom-role-name",
          "actions": ["create" | "read" | "update" | "delete" | "*"],
          "fields": {
            "include": ["field-name"],
            "exclude": ["field-name"]
          },
          "policy": {
            "database": "<Expression>"
          }
        }
      ]
    }
  }
}

Proprietà

	Obbligatorio	Digitare
`source`	✔️ Sì	oggetto
`permissions`	✔️ Sì	array
`rest`	❌ No	oggetto
`graphql`	❌ No	oggetto
`mappings`	❌ No	oggetto
`relationships`	❌ No	oggetto
`cache`	❌ No	oggetto

Esempi

Questo oggetto JSON, ad esempio, indica al generatore di API dati di esporre un'entità GraphQL denominata Author e un endpoint REST raggiungibile tramite il percorso /Author. La tabella di database dbo.authors supporta l'entità e la configurazione consente a chiunque di accedere all'endpoint in modo anonimo.

{
  "entities": {
    "Author": {
      "source": {
        "object": "dbo.authors",
        "type": "table"
      },
      "permissions": [
        {
          "role": "anonymous",
          "actions": [
            {
              "action": "*"
            }
          ]
        }
      ]
    }
  }
}

In questo esempio viene dichiarata l'entità User. Questo nome User viene usato in qualsiasi punto del file di configurazione a cui fanno riferimento le entità. In caso contrario, il nome dell'entità non è rilevante per gli endpoint.

{
  "entities": {
    "Book": {
      "rest": {
        "enabled": true,
        "path": "/books",
        "methods": ["GET", "POST", "PUT"]
      },
      "graphql": {
        "enabled": true,
        "type": {
          "singular": "Book",
          "plural": "Books"
        },
        "operation": "query"
      },
      "source": {
        "object": "BooksTable",
        "type": "table",
        "key-fields": ["Id"],
        "parameters": {}
      },
      "mappings": {
        "id": "Id",
        "title": "Title",
        "authorId": "AuthorId"
      },
      "permissions": [
        {
          "role": "authenticated",
          "actions": ["read"],
          "fields": {
            "include": ["id", "title"],
            "exclude": []
          },
          "policy": {
            "database": "@claims.userId eq @item.authorId"
          }
        },
        {
          "role": "admin",
          "actions": ["create", "read", "update", "delete"],
          "fields": {
            "include": ["*"],
            "exclude": []
          },
          "policy": {
            "database": "@claims.userRoles has 'BookAdmin'"
          }
        }
      ]
    }
  }
}

Fonte

OBBLIGATORIO: ✔️ Sì

La configurazione {entity}.source è fondamentale per definire la connessione tra l'entità esposta dall'API e il relativo oggetto di database sottostante. Questa proprietà specifica la tabella di database, la vista o la stored procedure rappresentata dall'entità, stabilendo un collegamento diretto per il recupero e la manipolazione dei dati.

Per scenari semplici, in cui l'entità esegue il mapping diretto a una singola tabella o raccolta di database, la proprietà di origine richiede solo il nome dell'oggetto di database. Questa semplicità facilita la configurazione rapida per i casi d'uso comuni.

Formato

{
  ...
  "entities" {
    "<entity-name>": {
      ...
      "source": {
        "object": "<string>",
        "type": "<view> | <stored-procedure> | <table>",
        "key-fields": [ "<array-of-strings>" ],
        "parameters": {
            "<name>": "<value>",
            "<name>": "<value>"
        }        
      }
    }
  }
}

Proprietà

	Obbligatorio	Digitare
`object`	✔️ Sì	corda
`type`	✔️ Sì	stringa enumerazione
`parameters`	❌ No	oggetto
`key-fields`	❌ No	matrice di stringhe

Esempi

Questo esempio mostra la struttura più semplice da associare a un'entità a una tabella di origine.

{
  "entities": {
    "Author": {
      "source": {
        "object": "dbo.authors",
        "type": "table"
      }
    }
  }
}

Ecco un exmaple di una relazione molti-a-molti.

Diagramma di una relazione molti-a-molti tra più tabelle di database

{
  "entities": {
    "Todo": {
      "type": "stored-procedure",
      "source": {
        "type": "stored-procedure",
        "object": "GetUserTodos"
      },
      "parameters": {
        "UserId": 0, 
        "Completed": null,
        "CategoryName": null
      },
      "mapping": {
        "Id": "todo_id",
        "Title": "todo_title",
        "Description": "todo_description",
        "Completed": "todo_completed"
      }
    }
  }
}

Entità Todo supportata da una stored procedure.
La proprietà type all'interno dell'origine è impostata su stored-procedure, che indica il tipo di oggetto di origine a cui è mappata l'entità.
La proprietà object all'interno dell'origine è il nome della stored procedure nel database.

In questo esempio viene aggiunta anche la proprietà (facoltativa) mapping alla configurazione per l'entità "Todo". Specifica il mapping dei campi nell'entità (Id, Title, Descriptione Completed) ai campi corrispondenti nei parametri dell'origine dati o della stored procedure sottostante ( rispettivamentetodo_id, todo_title, todo_descriptione todo_completed). Questo mapping garantisce che i dati corretti vengano passati tra l'entità e la stored procedure durante le operazioni di creazione/aggiornamento.

Nell'esempio precedente viene utilizzata la procedura SQL seguente.

CREATE PROCEDURE GetUserTodos
    @UserId INT,
    @Completed BIT = NULL,
    @CategoryName NVARCHAR(100) = NULL
AS
BEGIN
    SELECT t.*
    FROM Todo t
    INNER JOIN users_todos ut ON t.id = ut.todo_id
    INNER JOIN Category c ON t.category_id = c.id
    WHERE ut.user_id = @UserId
    AND ISNULL(@Completed, t.completed)
    AND ISNULL(@CategoryName, c.name)
END

@UserId: parametro obbligatorio senza un valore predefinito.
@Completed: parametro facoltativo. Se specificato, filtra i todos in base allo stato di completamento.
@CategoryName: parametro facoltativo. Se specificato, filtra i todos in base al nome della categoria.

Di seguito è riportato un esempio per gli aggiornamenti che usano una stored procedure.

{
  "entities": {
    "Todo": {
      "type": "stored-procedure",
      "source": {
        "object": "UpsertTodo"
      },
      "method": "POST", // Specify the HTTP method as POST
      "parameters": {
        "Id": 0,
        "Title": null,
        "Description": null,
        "Completed": null
      }
    }
  }
}

Questo esempio imposta in modo esplicito il metodo HTTP per interagire con questa entità su POST usando la proprietà del metodo .

CREATE PROCEDURE UpsertTodo
    @Id INT,
    @Title NVARCHAR(100),
    @Description NVARCHAR(255),
    @Completed BIT
AS
BEGIN
    SET NOCOUNT ON;

    MERGE INTO Todo AS target
    USING (VALUES (@Id, @Title, @Description, @Completed)) AS source (Id, Title, Description, Completed)
    ON target.Id = source.Id
    WHEN MATCHED THEN
        UPDATE SET
            Title = source.Title,
            Description = source.Description,
            Completed = source.Completed
    WHEN NOT MATCHED THEN
        INSERT (Id, Title, Description, Completed)
        VALUES (source.Id, source.Title, source.Description, source.Completed);
END;

Oggetto

OBBLIGATORIO: ✔️ Sì

Nome dell'oggetto di database da utilizzare.

Esempi

In questo esempio, object fa riferimento all'oggetto dbo.books nel database.

{
  "entities": {
    "Book": {
      "source": {
        "object": "dbo.books",
        "type": "table"
      }
    }
  }
}

Tipo (entità)

OBBLIGATORIO: ✔️ Sì

La proprietà type identifica il tipo di oggetto di database sottostante l'entità, tra cui view, tablee stored-procedure. La proprietà type è obbligatoria e non esiste un valore predefinito.

Formato

{
  "entities" {
    "<entity-name>": {
      "type": "<view> | <stored-procedure> | <table>",
      ...
    }
  }
}

Valori

Ecco un elenco di valori consentiti per questa proprietà:

	Descrizione
`table`	Rappresenta una tabella.
`stored-procedure`	Rappresenta una stored procedure.
`view`	Rappresenta una visualizzazione.

Esempi

In questo esempio, type indica che questa origine è una vista nel database. Questo valore influisce sul fatto che siano necessari altri valori (ad esempio, key-fields).

{
  "entities": {
    "Category": {
      "source": {
        "object": "dbo.vw_category_details",
        "type": "view",
        "key-fields": [
          "category_id"
        ]
      }
    }
  }
}

Campi chiave

REQUIRED: ❌ No

L'impostazione {entity}.key-fields è necessaria per le entità supportate dalle visualizzazioni, quindi Generatore API dati sa come identificare e restituire un singolo elemento, se necessario. Se type è impostato su view senza key-fields, il motore del generatore di API dati rifiuta l'avvio.

Importante

Questa proprietà è obbligatoria se il tipo di oggetto è un view. Inoltre, questa proprietà è obbligatoria è il tipo di oggetto è un table senza chiave primaria definita.

Formato

{
  "entities" {
    "<entity-name>": {
      ...
      "type": "view",
      "key-fields": [ "<field-name>" ]
    }
  }
}

Esempi

In questo esempio viene utilizzata la visualizzazione dbo.vw_category_details con category_id indicato come campo chiave.

{
  "entities": {
    "Category": {
      "source": {
        "object": "dbo.vw_category_details",
        "type": "view",
        "key-fields": [
          "category_id"
        ]
      }
    }
  }
}

Parametri

REQUIRED: ❌ No

L'impostazione {entity}.parameters è importante per le entità supportate dalle stored procedure, consentendo agli sviluppatori di specificare i parametri e i relativi valori predefiniti. I parametri assicurano che se alcuni parametri non vengono forniti all'interno di una richiesta HTTP, il sistema può eseguire il fallback a questi valori predefiniti.

Importante

Questa proprietà è obbligatoria se il tipo di oggetto è un stored-procedure.

Formato

{
  "entities" {
    "<entity-name>": {
      ...
      "type": "stored-procedure",
      "parameters": {
        "<parameter-name-1>" : "<default-value>",
        "<parameter-name-2>" : "<default-value>",
        "<parameter-name-3>" : "<default-value>"
      }
    }
  }
}

Esempi

In questo esempio viene richiamata la stored procedure dbo.stp_get_bestselling_books passando questi due parametri:

	Valore
`depth`	25
`list`	contoso-best-seller

{
  "entities": {
    "BestsellingBooks": {
      "source": {
        "object": "dbo.stp_get_bestselling_books",
        "type": "stored-procedure",
        "parameters": {
          "depth": 25,
          "list": "contoso-best-sellers"
        }
      }
    }
  }
}

Autorizzazioni

OBBLIGATORIO: ✔️ Sì

Questa sezione definisce chi può accedere all'entità correlata e quali azioni sono consentite. Le autorizzazioni sono definite in questa sezione nei termini dei ruoli. Le azioni vengono definite come operazioni CRUD tipiche, tra cui: create, read, updatee delete. La sezione permissions definisce chi (in termini di ruoli) può accedere all'entità correlata e a quali azioni. Le azioni sono le normali operazioni CRUD: create, read, update, delete.

Formato

{
  ...
  "entities": {
    "<entity-name>": {
      ...
      "permissions": [
        {
          ...
          "actions": [
            "create", 
            "read", 
            "update", 
            "delete", 
            "execute"
          ],
        }
      ]
    }
  }
}

Proprietà

	Obbligatorio	Digitare
`role`	✔️ Sì	corda
`actions` (matrice di stringhe) o `actions` (matrice di oggetti)	✔️ Sì	matrice di oggetti o stringhe

Esempi

In questo esempio viene definito un ruolo anonimo con accesso a tutte le azioni possibili.

{
  "entities": {
    "Writer": {
      "permissions": [
        {
          "role": "anonymous",
          "actions": ["*"]
        }
      ]
    }
  }
}

In alternativa, è possibile usare un oggetto per definire l'azione con caratteri jolly.

{
  "entities": {
    "Editor": {
      "permissions": [
        {
          "role": "anonymous",
          "actions": [
            {
              "action": "*"
            }
          ]        
        }
      ]
    }
  }
}

È anche possibile combinare e associare azioni stringa e matrice di oggetti.

{
  "entities": {
    "Reviewer": {
      "permissions": [
        {
          "role": "anonymous",
          "actions": [
            {
              "action": "read"
            },
            "create"
          ]        
        }
      ]
    }
  }
}

Ruolo anonimo Consenti agli utenti anonimi di leggere tutti i campi ad eccezione del secret-field. L'uso di "include": ["*"] con "exclude": ["secret-field"] nasconde in modo efficace secret-field da utenti anonimi, consentendo l'accesso a tutti gli altri campi.

Ruolo autenticato Consentire agli utenti autenticati di leggere e aggiornare campi specifici, inclusi in modo esplicito id, titlee secret-field, ma escludendo quindi secret-field. Illustra l'inclusione esplicita e l'esclusione successiva di secret-field, che mostra la precedenza di exclude. Poiché secret-field è incluso ed escluso, finisce per essere inaccessibile, che corrisponde alla regola prevista di exclude che ha la precedenza.

ruolo autore autori possono eseguire tutte le operazioni * in tutti i campi senza esclusioni. Il file indica "include": ["*"] con una matrice di "exclude": [] vuota concede l'accesso a tutti i campi, perché nessun campo viene escluso in modo esplicito.

Questa configurazione rappresenta l'impostazione predefinita se non viene specificato nulla.

"fields": {
  "include": [],
  "exclude": []
}

È in effetti identico a:

"fields": {
  "include": [ "*" ],
  "exclude": []
}

Considerare anche la configurazione seguente:

"fields": {
  "include": [],
  "exclude": ["*"]
}

La configurazione precedente specifica in modo efficace che nessun campo viene incluso in modo esplicito ("include": [] è vuoto, a indicare che non sono consentiti campi) e che tutti i campi vengono esclusi ("exclude": ["*"] utilizza il carattere jolly * per indicare tutti i campi).

uso pratico: una configurazione di questo tipo potrebbe sembrare controintuitiva poiché limita l'accesso a tutti i campi. Tuttavia, può essere usata in scenari in cui un ruolo potrebbe eseguire determinate azioni, ad esempio la creazione di un'entità, senza accedere ad alcun dato.

Lo stesso comportamento, ma con sintassi diversa, sarebbe:

"fields": {
  "include": ["Id", "Title"],
  "exclude": ["*"]
}

La configurazione precedente tenta di specificare che devono essere inclusi solo i campi Id e Title, indicando anche che tutti i campi devono essere esclusi con il carattere jolly * nella sezione exclude. Un altro modo per esprimere la stessa logica sarebbe:

"fields": {
  "include": ["Id", "Title"],
  "exclude": ["Id", "Title"]
}

Data la regola generale che l'elenco exclude ha la precedenza sull'elenco include, specificando exclude: ["*"] in genere significa che tutti i campi vengono esclusi, anche i campi elencati nella sezione include. Pertanto, a prima vista, questa configurazione potrebbe sembrare impedire che tutti i campi siano accessibili, poiché la regola di esclusione è dominante.

L'inverso: se lo scopo è concedere, accedere solo ai campi Id e Title, è più chiaro e affidabile specificare solo tali campi nella sezione include e non usare exclude con un carattere jolly. In alternativa, è possibile modificare la logica delle autorizzazioni del sistema in modo da soddisfare in modo esplicito tali casi, presupponendo che si sia in controllo della progettazione. Per esempio:

"fields": {
  "include": ["Id", "Title"],
  "exclude": []
}

Ruolo

OBBLIGATORIO: ✔️ Sì

Stringa contenente il nome del ruolo a cui si applica l'autorizzazione definita. La stringa role contiene il nome del ruolo a cui si applica l'autorizzazione definita.

I ruoli impostano il contesto delle autorizzazioni in cui deve essere eseguita una richiesta. Per ogni entità definita nella configurazione di runtime, è possibile definire un set di ruoli e autorizzazioni associate che determinano come è possibile accedere all'entità negli endpoint REST e GraphQL. I ruoli non sono additivi. Per altre informazioni sui ruoli, vedere autorizzazione.

Il generatore di API dati valuta le richieste nel contesto di un singolo ruolo:

Ruolo	Descrizione
`anonymous`	Non viene presentato alcun token di accesso
`authenticated`	Viene presentato un token di accesso valido
`<custom-role>`	Viene presentato un token di accesso valido e l'intestazione HTTP `X-MS-API-ROLE` è inclusa specificando un ruolo utente incluso anche nell'attestazione dei ruoli del token di accesso

Formato

{
  "entities": {
    "entity-name": {
      "permissions": [
        {
          "role": "anonymous" | "authenticated" | "custom-role",
          "actions": [
            "create",
            "read",
            "update",
            "delete",
            "execute", // only when stored-procedure
            "*"
          ],
          "fields": {
            "include": ["field-name", "field-name"],
            "exclude": ["field-name", "field-name"]
          }
        }
      ]
    }
  }
}

Esempi

Questo esempio definisce un ruolo denominato reader con solo autorizzazioni di read per l'endpoint.

{
  "entities": {
    "Book": {
      "permissions": [
        {
          "role": "reader",
          "actions": [
            "read"
          ]        
        }
      ]
    }
  }
}

Azioni (matrice di stringhe)

OBBLIGATORIO: ✔️ Sì

Matrice di valori stringa che illustra in dettaglio le operazioni consentite per il ruolo associato. Per gli oggetti di database table e view, i ruoli possono essere configurati in modo da usare qualsiasi combinazione di azioni create, read, updateo delete. Per le stored procedure, i ruoli possono avere solo l'azione execute. La matrice actions illustra in dettaglio le azioni consentite nel ruolo associato. Quando l'entità è una tabella o una vista, i ruoli possono essere configurati con una combinazione delle azioni: create, read, update, delete.

Azione	Operazione SQL
`*`	Carattere jolly, inclusa l'esecuzione
`create`	Inserire una o più righe
`read`	Selezionare una o più righe
`update`	Modificare una o più righe
`delete`	Eliminare una o più righe
`execute`	Esegue una stored procedure

Nota

Per le stored procedure, l'azione con caratteri jolly (*) si espande in un elenco che include solo l'azione execute. Per tabelle e viste, l'azione con caratteri jolly si espande in un elenco che include create, read, updatee delete azioni.

Esempi

In questo esempio vengono concesse le autorizzazioni create e read al primo ruolo denominato contributor. Il secondo ruolo denominato auditor ha solo autorizzazioni di delete.

{
  "entities": {
    "CheckoutLogs": {
      "permissions": [
        {
          "role": "auditor",
          "actions": [
            "delete"
          ]        
        },
        {
          "role": "contributor",
          "actions": [
            "read",
            "create"
          ]
        }
      ]
    }
  }
}

Ecco un altro esempio.

{
  ...
  "entities": {
    "<entity-name>": {
      ...
      "permissions": [
        {
          "role": "contributor",
          "actions": ["read", "create"]
        }
      ]
    }
  }
}

Azioni (matrice di oggetti)

OBBLIGATORIO: ✔️ Sì

Nota

Formato

{
  "entities": {
    "<string>": {
      "permissions": [
        {
          "role": "<string>",
          "actions": [
            {
              "action": "<string>",
              "fields": ["<string-array>"],
              "policy": "object"
            }
          ]
        }
      ]
    }
  }
}

Proprietà

	Obbligatorio	Digitare
`action`	✔️ Sì	corda
`fields`	❌ No	matrice di stringhe
`policy`	❌ No	oggetto

Esempi

In questo esempio viene concessa solo read'autorizzazione al ruolo auditor. Il ruolo auditor può leggere solo dati specifici usando il predicato definito in policy.database. Il ruolo auditor è limitato anche nei campi che può o non può leggere usando la proprietà fields.

{
  "entities": {
    "CheckoutLogs": {
      "permissions": [
        {
          "role": "auditor",
          "actions": [
            {
              "action": "read",
              "fields": {
                "include": ["*"],
                "exclude": ["last_updated"]
              },
              "policy": {
                "database": "@item.LogDepth lt 3"
              }
            }
          ]
        }
      ]
    }
  }
}

Azione

OBBLIGATORIO: ✔️ Sì

Specifica l'operazione specifica consentita nell'oggetto di database.

Valori

Ecco un elenco di valori consentiti per questa proprietà:

	Tabelle	Visualizzazioni	Stored procedure	Descrizione
`create`	✔️ Sì	✔️ Sì	❌ No	Creare nuovi elementi
`read`	✔️ Sì	✔️ Sì	❌ No	Punto legge gli elementi esistenti
`update`	✔️ Sì	✔️ Sì	❌ No	Aggiornare o sostituire gli elementi esistenti
`delete`	✔️ Sì	✔️ Sì	❌ No	Rimuovere elementi esistenti
`execute`	❌ No	❌ No	✔️ Sì	Eseguire operazioni a livello di codice

Esempi

Di seguito è riportato un esempio in cui anonymous gli utenti possono execute una stored procedure specifica e read una tabella specifica.

{
  "entities": {
    "Author": {
      "source": {
        "object": "dbo.authors",
        "type": "table"
      },
      "permissions": [
        {
          "role": "anonymous",
          "actions": [
            {
              "action": "read"
            }
          ]
        }
      ]
    },
    "BestSellingAuthor": {
      "source": {
        "object": "dbo.stp_get_bestselling_authors",
        "type": "stored-procedure",
        "parameters": {
          "depth": 10
        }
      },
      "permissions": [
        {
          "role": "anonymous",
          "actions": [
            {
              "action": "execute"
            }
          ]
        }
      ]
    }
  }
}

Campi

REQUIRED: ❌ No

Specifiche granulari per i campi specifici a cui è consentito l'accesso per l'oggetto di database. La configurazione del ruolo è un tipo di oggetto con due proprietà interne, include e exclude. Questi valori supportano la definizione granulare delle colonne di database (campi) a cui è consentito l'accesso nella sezione fields.

Formato

{
  ...
  "entities": {
    "<entity-name>": {
      ...
      "permissions": [
        {
          {
            ...
            "fields": {
              "include": ["<field-name>"],
              "exclude": ["<field-name>"]
            }
          }
        }
      ]
    }
  }
}

Esempi

In questo esempio, il ruolo anonymous può leggere da tutti i campi tranne id, ma può usare tutti i campi durante la creazione di un elemento.

{
  "entities": {
    "Author": {
      "permissions": [
        {
          "role": "anonymous",
          "actions": [
            {
              "action": "read",
              "fields": {
                "include": ["*"],
                "exclude": ["id"]
              }
            },
            { "action": "create" }
          ]
        }
      ]
    }
  }
}

Includere ed escludere il lavoro insieme. Il carattere jolly * nella sezione include indica tutti i campi. I campi indicati nella sezione exclude hanno la precedenza sui campi indicati nella sezione include. La definizione viene convertita in includere tutti i campi ad eccezione del campo 'last_updated'.

"Book": {
    "source": "books",
    "permissions": [
        {
            "role": "anonymous",
            "actions": [ "read" ],
            // Include All Except Specific Fields
            "fields": {
              "include": [ "*" ],
              "exclude": [ "secret-field" ]
            }
        },
        {
            "role": "authenticated",
            "actions": [ "read", "update" ],
            // Explicit Include and Exclude
            "fields": {
              "include": [ "id", "title", "secret-field" ],
              "exclude": [ "secret-field" ]
            }
        },
        {
            "role": "author",
            "actions": [ "*" ],
            // Include All With No Exclusions (default)
            "fields": {
              "include": ["*"],
              "exclude": []
            }
        }
    ]
}

Politica

REQUIRED: ❌ No

La sezione policy, definita per action, definisce le regole di sicurezza a livello di elemento (criteri di database) che limitano i risultati restituiti da una richiesta. La sottosezione database indica l'espressione dei criteri di database valutata durante l'esecuzione della richiesta.

Formato

{
  "entities": {
    "<entity-name>": {
      "permissions": [
        {
          "role": "<string>",
          "actions": [
            {
              "action": "<string>",
              "fields": ["<string-array>"],
              "policy": {
                "database": "<string>"
              }
            }
          ]
        }
      ]
    }
  }
}

Proprietà

	Obbligatorio	Digitare
`database`	✔️ Sì	corda

Descrizione

Criterio di database: un'espressione simile a OData che viene convertita in un predicato di query valuta il database, inclusi operatori come eq, lte gt. Affinché i risultati vengano restituiti per una richiesta, il predicato di query della richiesta risolto da un criterio di database deve restituire true durante l'esecuzione nel database.

Criteri elemento di esempio	Predicato
`@item.OwnerId eq 2000`	`WHERE Table.OwnerId = 2000`
`@item.OwnerId gt 2000`	`WHERE Table.OwnerId > 2000`
`@item.OwnerId lt 2000`	`WHERE Table.OwnerId < 2000`

Un predicate è un'espressione che restituisce TRUE o FALSE. I predicati vengono usati nella condizione di ricerca di clausole WHERE e clausole HAVING, le condizioni di join di clausole FROM e altri costrutti in cui è necessario un valore booleano. (Microsoft Learn Docs)

Criteri di database

È possibile usare due tipi di direttive per gestire i criteri di database durante la creazione di un'espressione di criteri di database:

Direttiva	Descrizione
`@claims`	Accedere a un'attestazione all'interno del token di accesso convalidato fornito nella richiesta
`@item`	Rappresenta un campo dell'entità per la quale sono definiti i criteri del database

Nota

Quando è configurata l'autenticazione app Web statiche di Azure (EasyAuth), sono disponibili un numero limitato di tipi di attestazioni da usare nei criteri di database: identityProvider, userId, userDetailse userRoles. Per altre informazioni, vedere la documentazione dati dell'entità client 'app Web statica di Azure.

Ecco alcuni criteri di database di esempio:

@claims.UserId eq @item.OwnerId
@claims.UserId gt @item.OwnerId
@claims.UserId lt @item.OwnerId

Generatore API dati confronta il valore dell'attestazione UserId con il valore del campo del database OwnerId. Il payload del risultato include solo i record che soddisfano sia i metadati della richiesta sia l'espressione dei criteri di database.

Limitazioni

I criteri di database sono supportati per tabelle e viste. Le stored procedure non possono essere configurate con i criteri.

I criteri di database non impediscono l'esecuzione delle richieste all'interno del database. Questo comportamento è dovuto al fatto che vengono risolti come predicati nelle query generate passate al motore di database.

I criteri di database sono supportati solo per la creazione di actions, lettura, aggiornamentoe eliminare. Poiché non è presente alcun predicato in una chiamata a una stored procedure, non possono essere accodati.

Operatori simili a OData supportati

Operatore	Descrizione	Sintassi di esempio
`and`	AND logico	`"@item.status eq 'active' and @item.age gt 18"`
`or`	OR logico	`"@item.region eq 'US' or @item.region eq 'EU'"`
`eq`	Uguale	`"@item.type eq 'employee'"`
`gt`	Maggiore	`"@item.salary gt 50000"`
`lt`	Meno di	`"@item.experience lt 5"`

Per altre informazioni, vedere operatori binari.

Operatore	Descrizione	Sintassi di esempio
`-`	Nega (numerico)	`"@item.balance lt -100"`
`not`	Negazione logica (NOT)	`"not @item.status eq 'inactive'"`

Per altre informazioni, vedere operatori unari.

Restrizioni relative al nome del campo dell'entità

Rules: deve iniziare con una lettera o un carattere di sottolineatura (_), seguito da un massimo di 127 lettere, caratteri di sottolineatura (_) o cifre (0-9).
Impatto: i campi che non sono aderendo a queste regole non possono essere usati direttamente nei criteri di database.
Soluzione: usare la sezione mappings per creare alias per i campi che non soddisfano queste convenzioni di denominazione; i mapping assicurano che tutti i campi possano essere inclusi nelle espressioni dei criteri.

Utilizzo di `mappings` per i campi non conformi

Se i nomi dei campi dell'entità non soddisfano le regole di sintassi OData o si vuole semplicemente eseguirne l'alias per altri motivi, è possibile definire alias nella sezione mappings della configurazione.

{
  "entities": {
    "<entity-name>": {
      ...
      "mappings": {
        "<field-1-name>" : "<field-1-alias>",
        "<field-2-name>" : "<field-2-alias>",
        "<field-3-name>" : "<field-3-alias>"
      }
    }
  }
}

In questo esempio, field-1-name è il nome del campo del database originale che non soddisfa le convenzioni di denominazione OData. La creazione di una mappa a field-1-name e field-1-alias consente di fare riferimento a questo campo nelle espressioni dei criteri di database senza problemi. Questo approccio non solo consente di aderire alle convenzioni di denominazione OData, ma migliora anche la chiarezza e l'accessibilità del modello di dati all'interno degli endpoint GraphQL e RESTful.

Esempi

Si consideri un'entità denominata Employee all'interno di una configurazione dell'API dati che usa sia le attestazioni che le direttive dell'elemento. Garantisce che l'accesso ai dati venga gestito in modo sicuro in base ai ruoli utente e alla proprietà dell'entità:

{
  "entities": {
    "Employee": {
      "source": {
        "object": "HRUNITS",
        "type": "table",
        "key-fields": ["employee NUM"],
        "parameters": {}
      },
      "mappings": {
        "employee NUM": "EmployeeId",
        "employee Name": "EmployeeName",
        "department COID": "DepartmentId"
      },
      "policy": {
        "database": "@claims.role eq 'HR' or @claims.UserId eq @item.EmployeeId"
      }
    }
  }
}

definizione di entità: l'entità Employee è configurata per le interfacce REST e GraphQL, a indicare che i dati possono essere sottoposti a query o manipolati tramite questi endpoint.

Configurazione origine: identifica il HRUNITS nel database, con employee NUM come campo chiave.

Mapping: gli alias vengono usati rispettivamente per eseguire il mapping di employee NUM, employee Namee department COID a EmployeeId, EmployeeNamee DepartmentId, semplificando rispettivamente i nomi dei campi e nascondendo potenzialmente i dettagli dello schema del database sensibili.

'applicazione criteri: la sezione policy applica criteri di database usando un'espressione simile a OData. Questo criterio limita l'accesso ai dati agli utenti con il ruolo HR (@claims.role eq 'HR') o agli utenti la cui attestazione UserId corrisponde EmployeeId, ovvero l'alias del campo , nel database (@claims.UserId eq @item.EmployeeId). Garantisce che i dipendenti possano accedere ai propri record solo a meno che non appartengano al reparto risorse umane. I criteri possono applicare la sicurezza a livello di riga in base alle condizioni dinamiche.

Banca dati

OBBLIGATORIO: ✔️ Sì

Questa proprietà indica l'espressione dei criteri di database valutata durante l'esecuzione della richiesta. La stringa di criteri è un'espressione OData che viene convertita in un predicato di query valutato dal database. Ad esempio, l'espressione di criteri @item.OwnerId eq 2000 viene convertita nel predicato della query WHERE <schema>.<object-name>.OwnerId = 2000.

Nota

Un predicato è un'espressione che evalute per TRUE, FALSEo UNKNOWN. I predicati vengono usati in:

Condizione di ricerca delle clausole di WHERE
Condizione di ricerca delle clausole di FROM
Condizioni di join delle clausole di FROM
Altri costrutti in cui è necessario un valore booleano.

Per altre informazioni, vedere predicati.

Affinché i risultati vengano restituiti per una richiesta, il predicato di query della richiesta risolto da un criterio di database deve restituire true durante l'esecuzione nel database.

È possibile usare due tipi di direttive per gestire i criteri di database durante la creazione di un'espressione di criteri di database:

	Descrizione
`@claims`	Accede a un'attestazione all'interno del token di accesso convalidato fornito nella richiesta
`@item`	Rappresenta un campo dell'entità per la quale sono definiti i criteri del database

Nota

Un numero limitato di tipi di attestazione è disponibile per l'uso nei criteri di database quando è configurata l'autenticazione di App Web statiche di Azure (EasyAuth). Questi tipi di attestazione includono: identityProvider, userId, userDetailse userRoles. Per altre informazioni, vedere dati dell'entità client di App Web statiche di Azure.

Esempi

Ad esempio, un'espressione di criteri di base può valutare se un campo specifico è true all'interno della tabella. In questo esempio viene valutato se il campo soft_delete è false.

{
  "entities": {
    "Manuscripts": {
      "permissions": [
        {
          "role": "anonymous",
          "actions": [
            {
              "action": "read",
              "policy": {
                "database": "@item.soft_delete eq false"
              }
            }
          ]
        }
      ]
    }
  }
}

I predicati possono anche valutare i tipi di direttiva claims e item. Questo esempio esegue il pull del campo UserId dal token di accesso e lo confronta con il campo owner_id nella tabella di database di destinazione.

{
  "entities": {
    "Manuscript": {
      "permissions": [
        {
          "role": "anonymous",
          "actions": [
            {
              "action": "read",
              "policy": {
                "database": "@claims.UserId eq @item.owner_id"
              }
            }
          ]
        }
      ]
    }
  }
}

Limitazioni

I criteri di database sono supportati per tabelle e viste. Le stored procedure non possono essere configurate con i criteri.
I criteri di database non possono essere usati per impedire l'esecuzione di una richiesta all'interno di un database. Questa limitazione è dovuta al fatto che i criteri di database vengono risolti come predicati di query nelle query di database generate. Il motore di database valuta infine queste query.
I criteri di database sono supportati solo per actionscreate, read, updatee delete.
La sintassi delle espressioni OData dei criteri di database supporta solo questi scenari.
- Operatori binari inclusi, ma non limitati a; and, or, eq, gte lt. Per altre informazioni, vedere BinaryOperatorKind.
- Operatori unari, ad esempio gli operatori - (negate) e not. Per altre informazioni, vedere UnaryOperatorKind.
I criteri di database hanno anche restrizioni correlate ai nomi dei campi.
- Nomi di campo entità che iniziano con una lettera o un carattere di sottolineatura, seguiti al massimo da 127 lettere, caratteri di sottolineatura o cifre.
- Questo requisito è in base alla specifica OData. Per altre informazioni, vedere OData Common Schema Definition Language.

Mancia

Non è possibile fare riferimento ai campi che non sono conformi alle restrizioni menzionate nei criteri di database. Come soluzione alternativa, configurare l'entità con una sezione mapping per assegnare alias conformi ai campi.

GraphQL (entità)

REQUIRED: ❌ No

Questo segmento fornisce l'integrazione di un'entità nello schema GraphQL. Consente agli sviluppatori di specificare o modificare i valori predefiniti per l'entità in GraphQL. Questa configurazione garantisce che lo schema rifletta in modo accurato la struttura e le convenzioni di denominazione previste.

Formato

{
  "entities" {
    "<entity-name>": {
      ...
      "graphql": {
        "enabled": <true> (default) | <false>,
        "type": {
          "singular": "my-alternative-name",
          "plural": "my-alternative-name-pluralized"
        },
        "operation": "query" | "mutation" (default)
      },
    }
  }
}

{
  "entities": {
    "<string>": {
      "graphql": "<boolean>"
    }
  }
}

{
  "entities": {
    "<string>": {
      "graphql": {
        "enabled": "<boolean>",
        "type": "<string-or-object>",
        "operation": "<enum-string>"
      }
    }
  }
}

Proprietà

	Obbligatorio	Digitare
`enabled`	❌ No	booleano
`type`	❌ No	stringa o oggetto
`operation`	❌ No	stringa enumerazione

Esempi

Questi due esempi sono equivalenti a livello funzionale.

{
  "entities": {
    "Author": {
      "graphql": true
    }
  }
}

{
  "entities": {
    "Author": {
      "graphql": {
        "enabled": true
      }
    }
  }
}

In questo esempio l'entità definita è Book, che indica che si sta gestendo un set di dati correlati ai libri nel database. La configurazione per l'entità Book all'interno del segmento GraphQL offre una struttura chiara su come deve essere rappresentata e interagita con in uno schema GraphQL.

proprietà Enabled: l'entità Book viene resa disponibile tramite GraphQL ("enabled": true), ovvero gli sviluppatori e gli utenti possono eseguire query o modificare i dati dei libri tramite operazioni GraphQL.

proprietà Type: l'entità viene rappresentata con il nome singolare "Book" e il nome plurale "Books" nello schema GraphQL. Questa distinzione garantisce che quando si eseguono query su un singolo libro o più libri, lo schema offre tipi denominati in modo intuitivo (Book per una singola voce, Books per un elenco), migliorando l'usabilità dell'API.

proprietà Operation: l'operazione è impostata su "query", a indicare che l'interazione primaria con l'entità Book tramite GraphQL deve eseguire query sui dati (recuperando) anziché modificarli (creazione, aggiornamento o eliminazione). Questa configurazione è allineata ai modelli di utilizzo tipici in cui i dati dei libri vengono letti più frequentemente rispetto alla modifica.

{
  "entities": {
    "Book": {
      ...
      "graphql": {
        "enabled": true,
        "type": {
          "singular": "Book",
          "plural": "Books"
        },
        "operation": "query"
      },
      ...
    }
  }
}

Tipo (entità GraphQL)

REQUIRED: ❌ No

Questa proprietà determina la convenzione di denominazione per un'entità all'interno dello schema GraphQL. Supporta sia i valori stringa scalari che i tipi di oggetto. Il valore dell'oggetto specifica le forme singolari e plurali. Questa proprietà fornisce un controllo granulare sulla leggibilità e sull'esperienza utente dello schema.

Formato

{
  "entities": {
    "<string>": {
      "graphql": {
        "type": "<string>"
      }
    }
  }
}

{
  "entities": {
    "<string>": {
      "graphql": {
        "type": {
          "singular": "<string>",
          "plural": "<string>"
        }
      }
    }
  }
}

Proprietà

	Obbligatorio	Digitare
`singular`	❌ No	corda
`plural`	❌ No	corda

Esempi

Per un maggiore controllo sul tipo GraphQL, è possibile configurare il modo in cui il nome singolare e plurale viene rappresentato in modo indipendente.

Se plural manca o omesso (ad esempio, valore scalare) Il generatore di API dati tenta di pluralizzare automaticamente il nome, seguendo le regole in inglese per la pluralizzazione (ad esempio: https://engdic.org/singular-and-plural-noun-rules-definitions-examples)

{
  "entities" {
    "<entity-name>": {
      ...
      "graphql": {
        ...
        "type": {
          "singular": "User",
          "plural": "Users"
        }
      }
    }
  }
}

È possibile specificare un nome di entità personalizzato usando il parametro type con un valore stringa. In questo esempio, il motore distingue automaticamente tra le varianti singolari e plurali di questo nome usando regole in inglese comuni per la pluralizzazione.

{
  "entities": {
    "Author": {
      "graphql": {
        "type": "bookauthor"
      }
    }
  }
}

Se si sceglie di specificare i nomi in modo esplicito, utilizzare le proprietà type.singular e type.plural. In questo esempio vengono impostati in modo esplicito entrambi i nomi.

{
  "entities": {
    "Author": {
      "graphql": {
        "type": {
          "singular": "bookauthor",
          "plural": "bookauthors"
        }
      }
    }
  }
}

Entrambi gli esempi sono equivalenti a livello funzionale. Entrambi restituiscono lo stesso output JSON per una query GraphQL che usa il nome dell'entità bookauthors.

{
  bookauthors {
    items {
      first_name
      last_name
    }
  }
}

{
  "data": {
    "bookauthors": {
      "items": [
        {
          "first_name": "Henry",
          "last_name": "Ross"
        },
        {
          "first_name": "Jacob",
          "last_name": "Hancock"
        },
        ...
      ]
    }
  }
}

Operazione (entità GraphQL)

REQUIRED: ❌ No

Per le entità mappate alle stored procedure, la proprietà operation definisce il tipo di operazione GraphQL (query o mutazione) in cui la stored procedure è accessibile. Questa impostazione consente l'organizzazione logica dello schema e la conformità alle procedure consigliate di GraphQL, senza alcun impatto sulle funzionalità.

Nota

Un'entità viene specificata come stored procedure impostando il valore della proprietà {entity}.type su stored-procedure. Nel caso di una stored procedure, viene creato automaticamente un nuovo tipo GraphQL executeXXX. Tuttavia, la proprietà operation consente allo sviluppatore di coerare la posizione di tale tipo nelle parti mutation o query dello schema. Questa proprietà consente l'hygene dello schema e non vi è alcun impatto funzionale indipendentemente dal valore operation.

Se mancante, il valore predefinito operation è mutation.

Formato

{
  "entities": {
    "<string>": {
      "graphql": {
        "operation": "<string-enum>"
      }
    }
  }
}

Valori

Ecco un elenco di valori consentiti per questa proprietà:

	Descrizione
`query`	La stored procedure sottostante viene esposta come query
`mutation`	La stored procedure sottostante viene esposta come mutazione

Esempi

Quando operation è mutation, lo schema GraphQL sarà simile al seguente:

type Mutation {
  executeGetCowrittenBooksByAuthor(
    searchType: String = "S"
  ): [GetCowrittenBooksByAuthor!]!
}

Quando operation è query, lo schema GraphQL sarà simile al seguente:

Lo schema GraphQL sarà simile al seguente:

type Query {
  executeGetCowrittenBooksByAuthor(
    searchType: String = "S"
  ): [GetCowrittenBooksByAuthor!]!
}

Nota

La proprietà operation riguarda solo la posizione dell'operazione nello schema GraphQL, non modifica il comportamento dell'operazione.

Abilitato (entità GraphQL)

REQUIRED: ❌ No

Abilita o disabilita l'endpoint GraphQL. Controlla se un'entità è disponibile tramite endpoint GraphQL. Attivando o disattivando la proprietà enabled, gli sviluppatori espongono in modo selettivo le entità dallo schema GraphQL.

Formato

{
  "entities" {
    "<entity-name>": {
      ...
      "graphql": {
        ...
        "enabled": true | false
      }
    }
  }
}

REST (entità)

REQUIRED: ❌ No

La sezione rest del file di configurazione è dedicata all'ottimizzazione degli endpoint RESTful per ogni entità di database. Questa funzionalità di personalizzazione garantisce che l'API REST esposta soddisfi requisiti specifici, migliorando sia l'utilità che le funzionalità di integrazione. Risolve potenziali mancate corrispondenze tra le impostazioni derivate predefinite e i comportamenti degli endpoint desiderati.

Formato

{
  "entities": {
    "<entity-name>": {
      "rest": {
        "enabled": <true> (default) | <false>,
        "path": "/entity-path", (default <entity-name>)
        "methods": ["GET", "POST" (default)]
      },
      ...
    }
  }
}

Proprietà

	Obbligatorio	Digitare
`enabled`	✔️ Sì	booleano
`path`	❌ No	corda
`methods`	❌ No	matrice di stringhe

Esempi

Questi due esempi sono equivalenti a livello funzionale.

{
  "entities": {
    "Author": {
      "source": {
        "object": "dbo.authors",
        "type": "table"
      },
      "permissions": [
        {
          "role": "anonymous",
          "actions": ["*"]
        }
      ],
      "rest": true
    }
  }
}

{
  "entities": {
    "Author": {
      ...
      "rest": {
        "enabled": true
      }
    }
  }
}

Ecco un altro esempio di configurazione REST per un'entità.

{
  "entities" {
    "User": {
      "rest": {
        "enabled": true,
        "path": "/User"
      },
      ...
    }
  }
}

Abilitato (entità REST)

REQUIRED: ❌ No

Questa proprietà funge da interruttore per la visibilità delle entità all'interno dell'API REST. Impostando la proprietà enabled su true o false, gli sviluppatori possono controllare l'accesso a entità specifiche, abilitando una superficie API personalizzata in linea con i requisiti di sicurezza e funzionalità delle applicazioni.

Se omesso o mancante, il valore predefinito di enabled è true.

Formato

{
  "entities" {
    "<entity-name>": {
      ...
      "rest": {
        "enabled": <true> (default) | <false>
      }
    }
  }
}

Percorso (entità REST)

REQUIRED: ❌ No

La proprietà path specifica il segmento URI usato per accedere a un'entità tramite l'API REST. Questa personalizzazione consente percorsi di endpoint più descrittivi o semplificati oltre il nome dell'entità predefinito, migliorando la navigazione api e l'integrazione lato client. Per impostazione predefinita, il percorso è /<entity-name>.

Formato

{
  "entities" {
    "<entity-name>": {
      ...
      "rest": {
        ...
        "path": "/entity-path"
      }
    }
  }
}

Esempi

In questo esempio viene esposta l'entità Author usando l'endpoint /auth.

{
  "entities": {
    "Author": {
      "rest": {
        "path": "/auth"
      }
    }
  }
}

Metodi (entità REST)

REQUIRED: ❌ No

Applicabile in modo specifico alle stored procedure, la proprietà methods definisce i verbi HTTP (ad esempio, GET, POST) a cui la routine può rispondere. I metodi consentono un controllo preciso sul modo in cui le stored procedure vengono esposte tramite l'API REST, garantendo la compatibilità con gli standard RESTful e le aspettative dei client. Questa sezione sottolinea l'impegno della piattaforma per la flessibilità e il controllo dello sviluppatore, consentendo una progettazione api precisa e intuitiva su misura per le esigenze specifiche di ogni applicazione.

Se omesso o mancante, il valore predefinito methods è POST.

Formato

{
  "entities" {
    "<entity-name>": {
      ...
      "rest": {
        ...
        "methods": [ "GET" (default), "POST" ]
      }
    }
  }
}

Valori

Ecco un elenco di valori consentiti per questa proprietà:

	Descrizione
`get`	Espone le richieste HTTP GET
`post`	Espone le richieste HTTP POST

Esempi

In questo esempio viene indicato al motore che la stored procedure stp_get_bestselling_authors supporta solo le azioni HTTP GET.

{
  "entities": {
    "BestSellingAuthor": {
      "source": {
        "object": "dbo.stp_get_bestselling_authors",
        "type": "stored-procedure",
        "parameters": {
          "depth": 10
        }
      },
      "rest": {
        "path": "/best-selling-authors",
        "methods": [ "get" ]
      }
    }
  }
}

Mapping (entità)

REQUIRED: ❌ No

Sezione mappings consente di configurare alias o nomi esposti per i campi oggetto di database. I nomi esposti configurati si applicano sia agli endpoint GraphQL che REST.

Importante

Per le entità con GraphQL abilitato, il nome esposto configurato deve soddisfare i requisiti di denominazione graphQL. Per altre informazioni, vedere specifica dei nomi GraphQL.

Formato

{
  ...
  "entities" {
    "<entity-name>": {
      "rest":{ ... },
      "graphql": { ... },
      "source": { ... },
      "mappings": {
        "<field-1-name>" : "<field-1-alias>",
        "<field-2-name>" : "<field-2-alias>",
        "<field-3-name>" : "<field-3-alias>"
      }
    }
  }
}

Esempi

In questo esempio, il campo sku_title dell'oggetto di database dbo.magazines viene esposto usando il nome title. Analogamente, il campo sku_status viene esposto come status negli endpoint REST e GraphQL.

{
  "entities": {
    "Magazine": {
      ...
      "mappings": {
        "sku_title": "title",
        "sku_status": "status"
      }
    }
  }
}

Ecco un altro esempio di mapping.

{
  "entities": {
    "Book": {
      ...
      "mappings": {
        "id": "BookID",
        "title": "BookTitle",
        "author": "AuthorName"
      }
    }
  }
}

Mapping: l'oggetto mappings collega i campi del database (BookID, BookTitle, AuthorName) a nomi più intuitivi o standardizzati (id, title, author) utilizzati esternamente. Questo aliasing serve a diversi scopi:

chiarezza e coerenza: consente l'uso di nomi chiari e coerenti nell'API, indipendentemente dallo schema del database sottostante. Ad esempio, BookID nel database viene rappresentato come id nell'API, rendendolo più intuitivo per gli sviluppatori che interagiscono con l'endpoint.
GraphQL Compliance: fornendo un meccanismo ai nomi dei campi alias, garantisce che i nomi esposti tramite l'interfaccia GraphQL siano conformi ai requisiti di denominazione di GraphQL. L'attenzione ai nomi è importante perché GraphQL ha regole rigorose sui nomi (ad esempio, senza spazi, deve iniziare con una lettera o un carattere di sottolineatura e così via). Ad esempio, se un nome di campo del database non soddisfa questi criteri, può essere aliasato a un nome conforme tramite mapping.
flessibilità: questo aliasing aggiunge un livello di astrazione tra lo schema del database e l'API, consentendo le modifiche in una senza richiedere modifiche nell'altra. Ad esempio, una modifica del nome di campo nel database non richiede un aggiornamento alla documentazione dell'API o al codice lato client se il mapping rimane coerente.
nome campo offuscamento: il mapping consente l'offuscamento dei nomi di campo, che consente agli utenti non autorizzati di dedurre informazioni riservate sullo schema del database o sulla natura dei dati archiviati.
Protezione delle informazioni proprietarie: rinominando i campi, è anche possibile proteggere i nomi proprietari o la logica di business che potrebbero essere specificati tramite i nomi dei campi originali del database.

Relazioni (entità)

REQUIRED: ❌ No

Questo mapping di sezioni include un set di definizioni di relazione che eseguono il mapping del modo in cui le entità sono correlate ad altre entità esposte. Queste definizioni di relazione possono anche includere facoltativamente dettagli sugli oggetti di database sottostanti usati per supportare e applicare le relazioni. Gli oggetti definiti in questa sezione vengono esposti come campi GraphQL nell'entità correlata. Per altre informazioni, vedere suddivisione delle relazioni del generatore di API dati.

Nota

Le relazioni sono rilevanti solo per le query GraphQL. Gli endpoint REST accedono a una sola entità alla volta e non possono restituire tipi annidati.

La sezione relationships descrive come le entità interagiscono all'interno del generatore di API dati, illustrano in dettaglio le associazioni e il potenziale supporto del database per queste relazioni. La proprietà relationship-name per ogni relazione è obbligatoria e deve essere univoca in tutte le relazioni per una determinata entità. I nomi personalizzati garantiscono connessioni chiare e identificabili e mantengono l'integrità dello schema GraphQL generato da queste configurazioni.

Relazione	Cardinalità	Esempio
uno-a-molti	`many`	Un'entità categoria può essere correlata a molte entità todo
molti-a-uno	`one`	Molte entità todo possono essere correlate a un'entità di categoria
molti-a-molti	`many`	Un'entità todo può essere correlata a molte entità utente e un'entità utente può essere correlata a molte entità todo

Formato

{{
  "entities": {
    "entity-name": {
      ...
      "relationships": {
        "relationship-name": {
          "cardinality": "one" | "many",
          "target.entity": "target-entity-name",
          "source.fields": ["source-field-name"],
          "target.fields": ["target-field-name"],
          "linking.object": "linking-object-name",
          "linking.source.fields": ["linking-source-field-name"],
          "linking.target.fields": ["linking-target-field-name"]
        }
      }
    }
  }
}

Proprietà

	Obbligatorio	Digitare
`cardinality`	✔️ Sì	stringa enumerazione
`target.entity`	✔️ Sì	corda
`source.fields`	❌ No	matrice di stringhe
`target.fields`	❌ No	matrice di stringhe
`linking.<object-or-entity>`	❌ No	corda
`linking.source.fields`	❌ No	matrice di stringhe
`linking.target.fields`	❌ No	matrice di stringhe

Esempi

Quando si considerano le relazioni, è consigliabile confrontare le differenze tra uno-a-molti, molti-a-uno e relazioni molti-a-molti.

Uno-a-molti

Si consideri innanzitutto un esempio di relazione con l'entità Category esposta con una relazione uno-a-molti con l'entità Book. In questo caso, la cardinalità è impostata su many. Ogni Category può avere più entità Book correlate, mentre ogni entità Book è associata solo a una singola entità Category.

{
  "entities": {
    "Book": {
      ...
    },
    "Category": {
      "relationships": {
        "category_books": {
          "cardinality": "many",
          "target.entity": "Book",
          "source.fields": [ "id" ],
          "target.fields": [ "category_id" ]
        }
      }
    }
  }
}

In questo esempio, l'elenco source.fields specifica il campo id dell'entità di origine (Category). Questo campo viene usato per connettersi all'elemento correlato nell'entità target. Viceversa, l'elenco target.fields specifica il campo category_id dell'entità di destinazione (Book). Questo campo viene usato per connettersi all'elemento correlato nell'entità source.

Con questa relazione definita, lo schema GraphQL esposto risultante dovrebbe essere simile a questo esempio.

type Category
{
  id: Int!
  ...
  books: [BookConnection]!
}

Molti-a-uno

Si consideri quindi molti-a-uno che imposta la cardinalità su one. L'entità Book esposta può avere una singola entità Category correlata. L'entità Category può avere più entità correlate Book.

{
  "entities": {
    "Book": {
      "relationships": {
        "books_category": {
          "cardinality": "one",
          "target.entity": "Category",
          "source.fields": [ "category_id" ],
          "target.fields": [ "id" ]
        }
      },
      "Category": {
        ...
      }
    }
  }
}

In questo caso, l'elenco source.fields specifica che il campo category_id dell'entità di origine (Book) fa riferimento al campo id dell'entità di destinazione correlata (Category). Inversamente, l'elenco target.fields specifica la relazione inversa. Con questa relazione, lo schema GraphQL risultante include ora un mapping da Libri a Categorie.

type Book
{
  id: Int!
  ...
  category: Category
}

Molti-a-molti

Infine, viene definita una relazione molti-a-molti con una cardinalità di many e più metadati per definire quali oggetti di database vengono usati per creare la relazione nel database di supporto. In questo caso, l'entità Book può avere più entità Author e viceversa l'entità Author può avere più entità Book.

{
  "entities": {
    "Book": {
      "relationships": {
        ...,
        "books_authors": {
          "cardinality": "many",
          "target.entity": "Author",
          "source.fields": [ "id" ],
          "target.fields": [ "id" ],
          "linking.object": "dbo.books_authors",
          "linking.source.fields": [ "book_id" ],
          "linking.target.fields": [ "author_id" ]
        }
      },
      "Category": {
        ...
      },
      "Author": {
        ...
      }
    }
  }
}

In questo esempio, il source.fields e target.fields indicano entrambi che la tabella delle relazioni usa l'identificatore primario (id) delle entità di origine (Book) e di destinazione (Author). Il campo linking.object specifica che la relazione è definita nell'oggetto di database dbo.books_authors. Inoltre, linking.source.fields specifica che il campo book_id dell'oggetto di collegamento fa riferimento al campo id dell'entità Book e linking.target.fields specifica che il campo author_id dell'oggetto di collegamento fa riferimento al campo id dell'entità Author.

Questo esempio può essere descritto usando uno schema GraphQL simile a questo esempio.

type Book
{
  id: Int!
  ...
  authors: [AuthorConnection]!
}

type Author
{
  id: Int!
  ...
  books: [BookConnection]!
}

Cardinalità

OBBLIGATORIO: ✔️ Sì

Specifica se l'entità di origine corrente è correlata solo a una singola istanza dell'entità di destinazione o a più.

Valori

Ecco un elenco di valori consentiti per questa proprietà:

	Descrizione
`one`	L'origine si riferisce solo a un record dalla destinazione
`many`	L'origine può essere correlata a record zero-a-molti dalla destinazione

Entità di destinazione

OBBLIGATORIO: ✔️ Sì

Nome dell'entità definita altrove nella configurazione che rappresenta la destinazione della relazione.

Campi di origine

REQUIRED: ❌ No

Parametro facoltativo per definire il campo usato per il mapping nell'entità di origine usata per connettersi all'elemento correlato nell'entità di destinazione.

Mancia

Questo campo non è obbligatorio se è presente una chiave esterna restrizione sul database tra i due oggetti di database che possono essere usati per dedurre automaticamente la relazione.

Campi di destinazione

REQUIRED: ❌ No

Parametro facoltativo per definire il campo usato per il mapping nell'entità di destinazione usata per connettersi all'elemento correlato nell'entità di origine.

Mancia

Questo campo non è obbligatorio se è presente una chiave esterna restrizione sul database tra i due oggetti di database che possono essere usati per dedurre automaticamente la relazione.

Collegamento di oggetti o entità

REQUIRED: ❌ No

Per le relazioni molti-a-molti, il nome dell'oggetto di database o dell'entità che contiene i dati necessari per definire una relazione tra due altre entità.

Collegamento dei campi di origine

REQUIRED: ❌ No

Nome dell'oggetto di database o del campo dell'entità correlato all'entità di origine.

Collegamento dei campi di destinazione

REQUIRED: ❌ No

Nome dell'oggetto di database o del campo dell'entità correlato all'entità di destinazione.

Cache (entità)

REQUIRED: ❌ No

Abilita e configura la memorizzazione nella cache per l'entità.

Formato

{
  "entities": {
    "<string>": {
      "cache": {
        "enabled": <true> | <false> (default),
        "ttl-seconds": (integer, default: 5)
      }
    }
  }
}

Proprietà

	Obbligatorio	Digitare	Default
`enabled`	❌ No	booleano	`false`
`ttl-seconds`	❌ No	numero intero	`5`

Esempi

In questo esempio la cache è abilitata e gli elementi scadono dopo 30 secondi.

{
  "entities": {
    "Author": {
      "cache": {
        "enabled": true,
        "ttl-seconds": 30
      }
    }
  }
}

Abilitato (entità cache)

REQUIRED: ❌ No

Abilita la memorizzazione nella cache per l'entità. L'impostazione predefinita è false: anche se l'impostazione globale è true.

Supporto degli oggetti di database

Tipo di oggetto	Supporto della cache
Tavolo	✅ Sì
Vista	✅ Sì
Stored Procedure	✖️ No
Contenitore	✖️ No

Supporto intestazione HTTP

Intestazione richiesta	Supporto della cache
`no-cache`	✖️ No
`no-store`	✖️ No
`max-age`	✖️ No
`public`	✖️ No
`private`	✖️ No
`etag`	✖️ No

Formato

{
  "entities": {
    "<string>": {
      "cache": {
        "enabled": "<boolean>"
      }
    }
  }
}

Esempi

In questo esempio la cache è disabilitata.

{
  "entities": {
    "Author": {
      "cache": {
        "enabled": false
      }
    }
  }
}

TTL in secondi (entità cache)

REQUIRED: ❌ No

Formato

{
  "entities": {
    "<string>": {
      "cache": {
        "ttl-seconds": <integer (inherited)>
      }
    }
  }
}

Esempi

In questo esempio la cache è abilitata e gli elementi scadono dopo 15 secondi. Se omesso, questa impostazione eredita l'impostazione globale o l'impostazione predefinita.

{
  "entities": {
    "Author": {
      "cache": {
        "enabled": true,
        "ttl-seconds": 15
      }
    }
  }
}

funzioni di riferimento
di riferimento dell'interfaccia della riga di comando

Condividi tramite

Informazioni di riferimento sullo schema di configurazione di Generatore API dati

Panoramica della sintassi

Proprietà di primo livello

Configurazione di esempio

Ambienti

Proprietà di configurazione

Schema

Formato

Esempi

Origine dati

Formato

Proprietà

Tipo di database

Formato

Valori

Stringa di connessione

Formato

Resilienza della connessione

SQL di Azure e SQL Server

Esempi

Opzioni

Formato

Esempi

File di origine dati

Formato

Considerazioni sul file di configurazione

Problemi noti

Esempi

Runtime

Formato

Proprietà

Esempi

GraphQL (runtime)

Formato

Proprietà

Abilitato (runtime GraphQL)

Formato

Esempi

Percorso (runtime GraphQL)

Formato

Esempi

Consenti introspezione (runtime GraphQL)

Formato

Esempi

Mutazioni multiple (runtime GraphQL)

Formato

Proprietà

Mutazioni multiple : creazione (runtime GraphQL)

Formato

Proprietà

Esempi

REST (runtime)

Formato

Proprietà

Abilitato (runtime REST)

Formato

Esempi

Percorso (runtime REST)

Formato

Esempi

Corpo della richiesta strict (runtime REST)

Formato

Esempi

Host (runtime)

Formato

Proprietà

Esempi

Modalità (runtime host)

Formato

Valori

CORS (runtime host)

Formato

Proprietà

Consenti credenziali (runtime host)

Formato

Origini (runtime host)

Formato

Esempi

Autenticazione (runtime host)