👋 @Marckman

Welcome to the Microcks community! 💖

Thanks and congrats 🎉 for opening your first issue here! Be sure to follow the issue template or please update it accordingly.

📢 If you're using Microcks in your organization, please add your company name to this list. 🙏 It really helps the project to gain momentum and credibility. It's a small contribution back to the project with a big impact.

If you need to know why and how to add yourself to the list, please read the blog post "Join the Microcks Adopters list and Empower the vibrant open source Community 🙌"

Hope you have a great time there!

🌟 ~~~~~~~~~ 🌟

📢 If you like Microcks, please ⭐ star ⭐ our repo to support it!

🙏 It really helps the project to gain momentum and credibility. It's a small contribution back to the project with a big impact.

Hello @Marckman,

I think reasoning from an example can help in this situation 😉 Let's imagine the following basic OpenAPI definition of your
service:

openapi: 3.0.2
info:
  title: MyService
  version: 1.0
paths:
  /resource:
    get:
      [...]

From this OpenAPI definition, Microcks will generate mock endpoints like this:
https://microcks.foo/rest/MyService/1.0/resource.
It can be seen as it is built that way:
https://{base.url}/{path} where base.url is actually https://microcks.foo/rest/MyService/1.0. The base.url is typically the thing that can change from environment to environment and that lives into environment variables or configuration properties.

Now if your current service has this kind of URL:
https://my.actual.env/MyService/api/v1/resource

You have several options the:

• Consider your base.url is https://my.actual.env/MyService and so update the path info of your spec to /api/v1/resource. That way, Microcks will produce URLs like https://microcks.foo/rest/MyService/1.0/api/v1/resource`
• Consider your base.url is https://my.actual.env/MyService/api and so update the path info of your spec to /v1/resource. That way, Microcks will produce URLs like https://microcks.foo/rest/MyService/1.0/v1/resource`
• Consider your base.url is https://my.actual.env/MyService/api/v1 and so keep the OpenAPI spec as is.

I hope it clarifies the situation on how Microcks is actually producing endpoint URLs.

Hi @lbroudoux, thanks a lot for the quick reply!
Please let me elaborate.

The actual service URL is set in stone and we cannot change it, i.e. it is always the hostname (env dependent) followed by the service name, a fixed api segment and the major version.
So the produced mock URL must be https://microcks.foo/rest/MyService/api/v1/resource, so I have tried to work around this problem following approaches similar to options 2 and 3 you just provided.

So if my spec is like this:

info:
  title: MyService
  version: api/v1
paths:
  /resource:

I get the error I mentioned in the first post. However, I have noticed versions with formats like api_v1 or api@v1 do work. I am currently looking into rewriting URLs on the ingress nginx side (replace that slash with _ or @) to make this option work.

Now, if I set the version as part of the resource:

info:
  title: MyService
  version: api
paths:
  /v1/resource:

This works really well but leads to a different problem: two major versions of the same API cannot live alongside each other (just like in the actual environments) because their "coordinates" (MyService/api) in Microcks are the same - in this case, I have noticed the previous artifact gets overwritten, forcing me to merge both specs before importing.

Finally, if the resource path is like api/v1/resource, this would leave the version empty, which I think is not allowed.

Hope this clarifies the issue a bit 🙂 Thanks again!

Ok I see what you mean but I'm afraid we cannot do something at the Microcks level as introducing version in endpoints is mandatory to avoid collision and version is of-course URL-encoded to avoid side-effect. In your situation, I would recommend adding an extra proxy in front of your Microcks instance to rewrite the URL the way you want.

You may then introduce an arbitrary version in your spec to have something like:

info:
  title: MyService
  version: 1.0
paths:
  /resource:

This would produce endpoints like https://microcks.foo/rest/MyService/1.0/resource but you'll put an Nginx or Traeffik in front of that to proxy https://my.actual.env/myservice/api/v1/resource to https://microcks.foo/rest/MyService/1.0/resource this would made the trick.

This could be a temporary situation until you realign your practices to some more standard ways like having https://my.actual.env/myservice/api being the base.url variable part as exposed before.

Thanks @lbroudoux.
We will keep working on the URL rewrite solution and adjust our specs accordingly.
Kind regards.