Dela via

Felsöka användningen av Data API Builder för Azure-databaser

  • Artikel

Den här artikeln innehåller lösningar på vanliga fel som kan uppstå när du använder Data API Builder för Azure-databaser.

Allmän slutpunkt: HTTP 400"Felaktig begäran"-fel

I följande avsnitt beskrivs orsakerna och lösningarna på HTTP 400-felet "Felaktig begäran".

Ogiltig slutpunkt för Data API Builder

Basen för URL-sökvägskomponenten mappar till Data API-byggarens REST- eller GraphQL-slutpunkt. När basen för URL-sökvägskomponenten inte matchar värdet som anges i Data API-byggarens körningskonfiguration returnerar Data API Builder ett HTTP 400-fel med "felaktig begäran".

Du kan konfigurera rotsökvägarna för GraphQL- och REST-slutpunkterna i avsnittet i runtime data-API-byggarens körningskonfiguration. Du måste använda värdena för att starta URL-sökvägarna för REST- och GraphQL-slutpunkterna.

Följande konfigurationsuppsättningar /api som rotsökväg för REST-slutpunkten och /graphql som rot för GraphQL-slutpunkten:

"runtime": {
    "rest": {
      "enabled": true,
      "path": "/api"
    },
    "graphql": {
      "allow-introspection": true,
      "enabled": true,
      "path": "/graphql"
    },
    "...": "...",
}

De värden som du måste använda i början av URL-sökvägarna för REST- och GraphQL-slutpunkterna är:

/api/<entity>

/graphql

Kommentar

När du använder Data API Builder med Static Web Apps med hjälp av funktionen Databasanslutningar börjar URL-sökvägen med /data-api. Du kan lägga till värdet för önskad slutpunkt efter det här värdet. Till exempel /data-api/api/<entity> för REST och /data-api/graphql GraphQL.

Konfigurationsproblem för Static Web Apps-databasanslutningar

När du använder data-API-byggare med funktionen Static Web Apps Database Connections visas felet "Svarsstatuskoden indikerar inte framgång: 400 (felaktig begäran)" i svarstexten:

{"Message":"{\u0022Message\u0022:\u0022Response status code does not indicate success: 400 (Bad Request).\u0022,\u0022ActivityId\u0022:\u0022<GUID>\u0022}","ActivityId":"<GUID>"}

Det här felet kan tyda på ett problem med den konfiguration som du angav när du länkade databasen.

Följ dessa anvisningar för att lösa problemet:

  1. Kontrollera att dina databasautentiseringsuppgifter är giltiga i ett verktyg som Azure Data Studio eller SQL Server Management Studio (SSMS).
  2. Ta bort länk/länka om den anslutna databasen.

Om du fortfarande stöter på felet kontrollerar du att du väljer Tillåt Azure-tjänster och resurser att komma åt den här servern för undantagen på nätverkssidan för din Azure Database-resurs. Det här alternativet konfigurerar brandväggen för att tillåta anslutningar från IP-adresser som allokerats till valfri Azure-tjänst eller tillgång, inklusive anslutningar från andra kunders prenumerationer.

Skärmbild som visar kryssrutan Tillåt Azure-tjänster och resurser att komma åt den här servern.

REST-slutpunkt: HTTP 404 -felet "Hittades inte"

Om den begärda URL:en pekar på en väg som inte är associerad med någon entitet returneras ett HTTP 404-fel. Som standard är entitetens namn också vägnamnet. Om du till exempel konfigurerar exempelentiteten Todo i konfigurationsfilen som i följande exempel:

"Todo": {
      "source": "dbo.todos",
      "...": "..."
    }

Sedan kan entiteten Todo nås via följande väg:

/<rest-route>/Todo

Om du anger rest.path egenskapen i entitetskonfigurationen till todo, som du ser i följande exempel:

"Todo": {
    "source": "dbo.todos",
    "rest": {
      "path": "todo"
    },
    "...": "..."
  }

Sedan är todoURL-vägen för entiteten Todo , med alla gemener som matchar det exakta värdet som definierats i körningskonfigurationen:

/<rest-route>/todo

GraphQL-slutpunkt: HTTP 400 fel med felaktig begäran

En GraphQL-begäran resulterar i ett HTTP 400-fel med "felaktig begäran" varje gång GraphQL-begäran konstrueras felaktigt. Det kan bero på ett icke-befintligt entitetsfält eller ett felstavat entitetsnamn. Data-API-byggare returnerar ett beskrivande fel och felinformation i svarsnyttolasten.

När du skickar en GET begäran till GraphQL-slutpunkten står det i svarstexten för det returnerade felet " Antingen måste parameterfrågan eller parameter-ID:t anges." Se till att skicka GraphQL-begäranden med HTTP POST.

GraphQL-slutpunkt: HTTP 404-felet "Hittades inte"

Kontrollera att GraphQL-begäran skickas till den konfigurerade GraphQL-slutpunkten med hjälp av HTTP-metoden POST . Som standard är /graphqlGraphQL-slutpunktsvägen .

GraphQL-slutpunkt: "Objekttypen Fråga måste minst definiera ett fält för att vara giltigt" fel

När det inte går att generera ett GraphQL-schema baserat på körningskonfigurationen får du felmeddelandet :

Objekttypen Fråga måste minst definiera ett fält för att vara giltigt.

GraphQL-specifikationen kräver att minst ett Query objekt definieras i GraphQL-schemat. Du måste kontrollera att körningskonfigurationen uppfyller något av följande villkor:

  • Åtgärden read definieras för minst en GraphQL-aktiverad entitet. GraphQL är aktiverat på entiteter som standard, så se till att du inte tillämpar den här åtgärden på en entitet som har konfigurerats med {"graphql": false}.

  • När du bara exponerar lagrade procedurer definierar du { "graphql": { "operation": query" } } på minst en lagrad procedurentitet, vilket åsidosätter den lagrade standardproceduren GraphQL-åtgärdstypen mutation.

    Du måste ha minst en lagrad procedur som bara läser och inte ändrar data. Annars misslyckas GraphQL-schemagenereringen på grund av ett tomt query fält i schemat.

GraphQL-slutpunkt: Introspektion fungerar inte med GraphQL-slutpunkten

Verktyg som stöder GraphQL använder normalt GraphQL-schema introspektion utan att kräva extra installation. Kontrollera att du anger egenskapen allow-introspection för körningskonfiguration till true i konfigurationsavsnittet runtime.graphql . Till exempel:

"runtime": {
    "...": "...",
    "graphql": {
      "allow-introspection": true,
      "enabled": true,
      "path": "/graphql"
    },
    "...": "..."
}

GraphQL-slutpunkt: Felet "Mutationsåtgärden <operation_name> lyckades men den aktuella användaren har inte behörighet att visa svaret på grund av brist på läsbehörigheter"

För att en GraphQL-mutationsåtgärd ska få ett giltigt svar bör läsbehörigheter konfigureras utöver respektive mutationsåtgärdstyp – skapa, uppdatera och ta bort. Som felet antyder lyckades mutationsåtgärden (skapa/uppdatera/ta bort) på databaslagret, men bristen på läsbehörighet gjorde att Data API-byggare returnerade ett felmeddelande. Så se till att konfigurera läsbehörigheter antingen i rollen "Anonym" eller den roll som du vill köra mutationsåtgärden med.

Allmänt fel: HTTP 500-fel som returneras av begäranden

HTTP 500-fel indikerar att Data API Builder inte kan fungera korrekt på serverdelsdatabasen. Se till att möta följande villkor:

  • Data-API-byggare kan fortfarande ansluta till den konfigurerade databasen.
  • Databasobjekten som används av Data API Builder är fortfarande tillgängliga och tillgängliga.

Om du vill tillåta att Data API Builder returnerar specifika databasfel i svar anger du konfigurationsegenskapen runtime.host.mode till development:

"runtime": {
    [...]
    "host": {
        "mode": "development",
        [...]
    }
}

Som standard körs Data API Builder med runtime.host.mode som är inställt på production. I production läge returnerar data-API-byggare inte detaljerade fel i svarsnyttolasten.

I både development lägen och production lägen skriver Data API Builder detaljerade fel till konsolen för att hjälpa till med felsökning.

Allmänna fel på grund av oautentiserade och obehöriga begäranden

HTTP 401 "Obehörigt" fel

HTTP 401-fel uppstår när slutpunkten och entiteten som används kräver autentisering och beställaren inte tillhandahåller giltiga autentiseringsmetadata i sin begäran.

När du konfigurerar data-API-byggare för att använda Microsoft Entra-ID-autentisering resulterar dina begäranden i HTTP 401-fel när den angivna ägartoken (åtkomst) är ogiltig. En åtkomsttoken kan vara ogiltig av många orsaker. Här är några av dem:

  • Åtkomsttoken har upphört att gälla.
  • Åtkomsttoken är inte avsedd för Data API-byggarens API (målgrupp för fel åtkomsttoken).
  • Åtkomsttoken skapas inte av den förväntade utfärdaren (ogiltig utfärdare av åtkomsttoken).

Lös det här felet genom att se till att uppfylla följande villkor:

  • Du genererar en åtkomsttoken med det issuer värde som definierats i authentication avsnittet i körningskonfigurationen.

  • Din åtkomsttoken genereras för det audience värde som definierats i authentication avsnittet i körningskonfigurationen.

Här är en exempelkonfiguration:

"authentication": {
    "provider": "AzureAD",
    "jwt": {
        "issuer": "https://login.microsoftonline.com/24c24d79-9790-4a32-bbb4-a5a5c3ffedd5/v2.0/",
        "audience": "b455fa3c-15fa-4864-8bcd-88fd83d686f3"
    }
}

Du måste generera en giltig token för den definierade målgruppen. När du använder Azure CLI kan du hämta en åtkomsttoken genom att ange målgruppen i parametern resource :

az account get-access-token --resource "b455fa3c-15fa-4864-8bcd-88fd83d686f3"

HTTP 403 "Förbjudet" fel

Om du skickar en autentiserad begäran med hjälp av Static Web Apps-integrering eller Microsoft Entra-ID kan du få felet HTTP 403 "Förbjuden". Det här felet anger att du försöker använda en roll som inte finns i konfigurationsfilen.

Det här felet inträffar i följande fall:

  • Du anger inte ett X-MS-API-ROLE HTTP-huvud som anger ett rollnamn.

    Eftersom autentiserade begäranden körs i kontexten för systemrollen authenticated som standard gäller det här scenariot endast när du använder en icke-systemroll (inte authenticated eller anonymous).

  • Den roll som du definierar i X-MS-API-ROLE rubriken är inte konfigurerad i data-API-byggarens körningskonfigurationsfil.

  • Den roll som du definierar i X-MS-API-ROLE rubriken matchar inte rollen i din åtkomsttoken.

I följande körningskonfigurationsfil definieras till exempel rollen role1 , så du måste ange ett X-MS-API-ROLE HTTP-huvud med värdet role1.

Kommentar

Matchningen av rollnamn är skiftlägeskänslig.

"Todo": {
    "role": "role1",
    "actions": [ "*" ]
}

Referenser

Gå vidare

Om problemet inte har lösts kan du ge feedback eller rapportera det i diskussioner med data-api-builder.

Kontakta oss för att få hjälp

Om du har frågor eller behöver hjälp skapar du en supportförfrågan eller frågar Azure community support. Du kan också skicka produktfeedback till Azure-feedbackcommunityn.