Layer7 API Management

Hi, 

I wanted to know if it's possible to specify parameters/variable of type "path" in custom resolution path of a service ? 

like "/api/user/{userid}" 

Thanks in advance.

Good Afternoon,

The value of {userid} when entered in the custom URI path will not be treated as a variable but as the text that is entered. If you want to have all userids picked up for the URI you would wildcard this to /api/user/*.

Sincerely,

Stephen Hughes

Director, CA Support

Thank you Stephen, 

So there is no way to specify such a variable in the path ? I put { } as example, i don't know if it's feasible.

Thank you.

If you are looking to use the value after the /api/user/ then I would recommend using the * at the end then in the policy use a regular expression to pull the value from the context variable ${request.http.uri} with the expression "/api/user/(.*)". Please let me know if this will work or if I'm missing something of what you are trying to do with the {userid} variable.

Sincerely,

Stephen Hughes

Director, CA Support

In fact, my idea is to put several variables in that path, like it's supported in a swagger specification of a service/api

We could have, for example, in addition of user id : 

/api/user/{userId}/order/{orderId}

And, for example, another service that will be a slightly different path, but forward to a different backend (so we can't use the wildcard)

/api/user/{userId}/invoice/{invoiceId}

Thank You.

There are several ways that you can accomplish this either in policy workflow or by using multiple wildcards. The policy workflow can use the Publish Swagger Service Wizard (https://docops.ca.com/ca-api-gateway/9-2/en/services-and-policies/tasks-manage-menu-publish-services-and-apis/publish-swagger-service-wizard) along with logic making different decisions based on aspects of the URI. The multiple wildcards could be that you establish a baseline for all items going to /api/user/* then add in additional ones /api/user/*/order/* and /api/user/*/invoice/*.

Sincerely,

Stephen Hughes

Director, CA Support

Thank you Stephen.

This is clearly a way to do it, but it is rather difficult to protect backend this way from incorrectly built requests.

Thanks anyway for your answer

Hi, using a custom resolution path like: /api/user/*/order/*  does not work... only works if then you use an actual "*" in the URL, but not using something like

/api/user/4124/order/222

Can this really be achieved?

Good afternoon,

Did my last response help you?

Sincerely,

Stephen Hughes

Director, CA Support

Hi Emmanuel,

You can specify wildcards within your path and have it resolve to the correct service. There are a few things that need to be implemented:

1. FastResolveService Assertion - Normally, we collect all the services and match an API to the most “greedy” service. When using the FastResolveService Assertion, we don’t follow a “greedy” approach and try to match the API to the best service.

2. Regular Expressions - This will assist in making that best match.

3. Message-Received Policy - You'll need to use the message-received policy for the services to resolve properly. 

I can provide you with a working use case for testing but you will need to open a Support ticket so I can provide you with the FastResolveService assertion. If you have any other questions or it's not working as expected, I'll be happy to assist you.

*~Jameela~*