How to Catch all even without the placeholder?

[LassazVegaz]

I have the configuration as below,

{
  "Routes": [
    {
      "UpstreamHttpMethod": [],
      "UpstreamPathTemplate": "/api/items/{everything}",
      "DownstreamPathTemplate": "/api/items/{everything}",
      "DownstreamScheme": "http",
      "DownstreamHostAndPorts": [
        {
          "Host": "localhost",
          "Port": 8102
        }
      ]
    }
  ],
  "GlobalConfiguration": {
    "BaseUrl": "http://localhost:8100"
  }
}

If the client sends a request to http://localhost:8100/api/items ocelot does not call http://localhost:8102/api/items (the downstream API). Ocelot returns a not-found status response.
I want Ocelot to call the given downstream API even without the placeholder. And without redeclaring the whole routing object just without the placeholder.

I went through Routing and Configuration documentation and general Google search, but could not find a solution. Can you please help?

[raman-m]

Hi Lasindu!
Welcome to Ocelot world! 🐯

According to the Catch All docs to make route /api/items/ functioning you have to define this route:
"The Catch All has a lower priority than any other Route."

So, the /api/items/{everything} route has lower priority.

Finally, I would say your routes should be:

{
  "Routes": [
    {
      "UpstreamPathTemplate": "/api/items/{everything}",
      "DownstreamPathTemplate": "/api/items/{everything}",
      // other props
    },
    {
      "UpstreamPathTemplate": "/api/items/",
      "DownstreamPathTemplate": "/api/items/",
      // other props
    }
  ],
  "GlobalConfiguration": { }
}

But... I recommend you a life hack to merge both routes to the one:

{
  "Routes": [
    {
      "UpstreamPathTemplate": "/api/{everything}",
      "DownstreamPathTemplate": "/api/{everything}",
      // other props
    }
  ],
  "GlobalConfiguration": { }
}

So, now the /api/items/ URL is included in Catch All route. 😉 Try it!
Hope it helps!

[LassazVegaz]

Hey
Thanks, man.
But I actually knew your first approach, that is why I asked

without redeclaring the whole routing object just without the placeholder

Your second solution doesn't really work for me. I have other routes starting with /api that should be mapped to different microservices.

Don't you think it is good to implement a feature? I have that wso2 integration studio has this feature. It can be really useful. I finished most of the routes and I had to define all of them twice. Now if I have to change the port of a microservice, I have to change it in two places.

[raman-m]

You ask strange question...
🆗 Anyway, answering the question "How to Catch all even without the placeholder?"

Answer ⬇️

It is impossible to catch all paths/URLs without a placeholder in the form {...}.
If you define single /api/items/ route then you will be able to process single URL only!
Hope you've got the answer you wanted.

[raman-m]

Don't you think it is good to implement a feature? I have that wso2 integration studio has this feature. It can be really useful. I finished most of the routes and I had to define all of them twice. Now if I have to change the port of a microservice, I have to change it in two places.

Sorry, but I don't understand you. Which feature are you talking about?

[LassazVegaz]

Forwarding all the requests starting with a URL potion to a given URL appending the remaining potion from the request URL.

With the current implementation of Ocelot, a developer has to define the same route twice. If the port of a microservice changes, then two places should be changed. Which could be done by just changing one place. Due to this, the above feature is generally implemented in API gateways.

It is not a strange requirement, it is a general requirement when it comes to microservices.

[raman-m]

If the port of a microservice changes, then two places should be changed.

If the service port or host changes, you need/have to use a service discovery approach!

[raman-m]

@LassazVegaz on Jan 4:

Which could be done by just changing one place. Due to this, the above feature is generally implemented in API gateways.

Current Catch All logic will remain as-is. Refactoring will introduce huge & significant breaking changes of the product current features! Current everything Catch-All feature won't be changed to have one single route for your rare user case needs!

But... merging both routes to the one makes sense. I agree!
As an option we could add new property for exclusive catch all approach like this:

Given: Catch All routes are /path/ and /path/{everything}
Required:

• main root /path/ should be able to have high priority and take responsibilities of /path/{everything} route
• main root should be switched on into exclusive mode via new "ExclusiveCatchAll" Boolean property
• definition of /path/{everything} route is not required in exclusive mode and will be ignored
• Query string Catch All route definition is not required too (aka /path/?{everything}) in exclusive mode and will be ignored

Is that something you're looking for? It should function as other gateways products to handle and process all URLs by Catch All approach.
In JSON:

{
  "Routes": [
    {
      "UpstreamPathTemplate": "/api/items/",
      "DownstreamPathTemplate": "/api/items/",
      "ExclusiveCatchAll": true // new required property
    },
    // Routes below are not required, so ignored
    {
      "UpstreamPathTemplate": "/api/items/{everything}",
      "DownstreamPathTemplate": "/api/items/{everything}"
    },
    {
      "UpstreamPathTemplate": "/api/items/?{everything}",
      "DownstreamPathTemplate": "/api/items/?{everything}"
    }
  ]
}

Looks good?

[LassazVegaz]

Yeah. You got it alright. Thanks. I can do it with a little guidance. I haven't check this repo's code.

But I do not agree with

rare user case

Is it very rare to have a microservice that exposes a couple of endpoints that start with /api/items?
For example:
create & delete
also, some endpoints that append extra URL potions to /api/items
update and delete -> /api/items/{id}
Search -> /api/items?name='abcd'&amount='10'
check if the item name exists -> /api/items/nameExists/{name}

[raman-m]

But I do not agree with
rare user case

🤣 Right! But Ocelot has current Routing and Catch All features being designed in the past. We should care about backward compatibility!

---

update and delete -> /api/items/{id}
check if the item name exists -> /api/items/nameExists/{name}

Are you sure you need these Placeholders in exclusive Catch All mode?
I don't see any sense in their definition for your user scenario with single route.

---

I can do it with a little guidance. I haven't check this repo's code.

🆗 man! Your expertise is JavaScript, TypeScript and Java as I see in your repos... Do you develop with C# lang?
Please confirm that you're going to work on that feature and contribute?
You can start development and create a PR... Later I will create official issue by converting this discussion. You could link this discussion to a PR too.
But first, you need to fork the Ocelot repo because our dev process requires forking!

[LassazVegaz]

I will work on this