API Management service - 2 APIs for same service

I have a service that has a C# OData query, plus multiple non-OData queries. I'm hooking it up to my APIM, and I would like to create 2 APIs for this inside the APIM:

• https://<myurl>/<myservice>/odata => an OData API
• https://<myurl>/<myservice>/xxxx => a manual HTTP API, where I'll define all the other operations inside

I'm trying to figure out the best way to do this, since they're both pointing to the same service, and both using the same base URL.

Right now I have all the calls inside an HTTP API policy, but I would like to break the OData one out, if possible

but I would like to break the OData one out, if possible

Create two separate APIs with URL rewriting.

<!-- In the OData API policy -->
<policies>
    <inbound>
        <base />
        <rewrite-uri template="/odata/{*remainder}" />
        <set-backend-service base-url="https://your-backend-service.com" />
    </inbound>
</policies>

<!-- In the HTTP API policy -->
<policies>
    <inbound>
        <base />
        <rewrite-uri template="/api/{*remainder}" />
        <set-backend-service base-url="https://your-backend-service.com" />
    </inbound>
</policies>

• Two separate APIs offers cleaner separation of concerns and Easier to manage different security policies and also have different rate limits for OData vs regular endpoints

Use a single API with path-based routing in the policy

<policies>
    <inbound>
        <base />
        <choose>
            <when condition="@(context.Request.OriginalUrl.Path.StartsWith("/odata"))">
                <!-- OData specific policies -->
                <set-header name="Prefer" exists-action="override">
                    <value>odata.maxpagesize=50</value>
                </set-header>
            </when>
            <otherwise>
                <!-- Regular API specific policies -->
            </otherwise>
        </choose>
        <set-backend-service base-url="https://your-backend-service.com" />
    </inbound>
</policies>

• Single API with routing offers shared policies where needed and single place to manage common settings

Both OData API and Regular API can point to the same backend service, but you will have better control over each API's behavior.