API returns 404 despite a working backend

Question

I'm trying to connect a basic Function App with a basic API Management instance. I've tried Azure Portal. Unfortunately, following doc page doesn't work. Here is what I've done:

I've successfully created an Azure Function with url https://myfuncappruftisoiqarzg.azurewebsites.net/api/funcfromcli Upon GET request, the url returns 200 and works successfully. I use this as my Web Service URL.

Then, in Portal, I create a basic HTTP API named test and a basic GET operation named op1. So, the request URL becomes https://myapiruftisoiqarzg.azure-api.net/test/op1 .Then, when I try to test request URL using Portal or making a GET request using Postman I get this error:

{
    "statusCode": 404,
    "message": "Resource not found"
}

I've disabled authorization and authentication using subscription id. My Web Service URL works well but request URL returns error. Can someone please tell me what's the issue?

Below, you can see the test fails.

Below is the OpenAPI specs:

{
    "openapi": "3.0.1",
    "info": {
        "title": "test",
        "description": "",
        "version": "1.0"
    },
    "servers": [{
        "url": "http://myapiruftisoiqarzg.azure-api.net/test"
    }, {
        "url": "https://myapiruftisoiqarzg.azure-api.net/test"
    }],
    "paths": {
        "/op1": {
            "get": {
                "summary": "op1",
                "operationId": "op1",
                "responses": {
                    "200": {
                        "description": null
                    }
                }
            }
        }
    },
    "components": {
        "securitySchemes": {
            "apiKeyHeader": {
                "type": "apiKey",
                "name": "Ocp-Apim-Subscription-Key",
                "in": "header"
            },
            "apiKeyQuery": {
                "type": "apiKey",
                "name": "subscription-key",
                "in": "query"
            }
        }
    },
    "security": [{
        "apiKeyHeader": []
    }, {
        "apiKeyQuery": []
    }]
}

Answer 1

Hello, Welcome to MS Q&A

Please try once with updated api spec

{
    "openapi": "3.0.1",
    "info": {
        "title": "test",
        "description": "",
        "version": "1.0"
    },
    "servers": [
        {
            "url": "https://myapiruftisoiqarzg.azure-api.net"
        }
    ],
    "paths": {
        "/test/op1": {
            "get": {
                "summary": "op1",
                "operationId": "op1",
                "responses": {
                    "200": {
                        "description": "Successful response"
                    }
                }
            }
        }
    },
    "components": {
        "securitySchemes": {
            "apiKeyHeader": {
                "type": "apiKey",
                "name": "Ocp-Apim-Subscription-Key",
                "in": "header"
            },
            "apiKeyQuery": {
                "type": "apiKey",
                "name": "subscription-key",
                "in": "query"
            }
        }
    },
    "security": [
        {
            "apiKeyHeader": []
        },
        {
            "apiKeyQuery": []
        }
    ]
}

Changes Made:

1. Server URL: Changed url in the servers section to https://myapiruftisoiqarzg.azure-api.net without additional path segments, as APIM will handle the /test segment based on the operation.
2. Path: Updated the path to /test/op1, aligning it with the APIM frontend path in the operation.
3. Response Description: Added a brief description for clarity.

This spec should now align with the expected routing and configuration in APIM. After updating, re-import this specification into APIM to apply the changes.

Also Check the following settings in your Function App:

• CORS Settings: If CORS is enabled, ensure APIM’s domain (myapiruftisoiqarzg.azure-api.net) is added as an allowed origin.
• IP Restrictions: Ensure there are no IP restrictions blocking APIM’s traffic in your Function App’s Networking settings.

If still issue occur , please let us know

Thanks

Deepanshu