You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
the given path might contain the entire path as it is exposed on the API-Gateway. But, the path is used to lookup the schema as defined in API-Specification and obviously it fails, when the path includes the customer specific exposure path.
For example when the Petstore is exposed on the API-Manager customers might configure them with a different exposure path: /api/petstore/v3.
At runtime, a number of variables contain the API-Path, but all of them include the Frontend-API exposure path. For instance: /api/petstore/v3/store/order/123456.
To simplify the use of this plugin, the validator should support such a path, even if it contains the frontend API Exposure path.
This should eliminate the need to manipulate the path variable in the scripting code and thus complicate the code unnecessarily.
The text was updated successfully, but these errors were encountered:
cwiechmann
changed the title
Given path variable should support the exposure path
Given path variable should support the full exposure path
Dec 21, 2021
The given path might be the FE-API exposure path which is not guaranteed to be part of the API-Specification.
If for example the Petstore is exposed with /petstore/v3 the path we get might be /api/petstore/v3/store/order/78787
and with that, the validation fails with the following error, as the specification doesn't contain this path.
No API path found that matches request '/api/petstore/v3/store/order/78787'.
As part of this new feature, the validator is trying up to 5 times to perform the validation and each time, it's removing the first part of the path:
Validate request: [verb: DELETE, path: '/api/petstore/v3/store/order/1234', payload: 'N/A']
No API path found that matches request '/api/petstore/v3/store/order/1234'.
Retrying validation with reduced path: '/petstore/v3/store/order/1234'] (1/5)
No API path found that matches request '/petstore/v3/store/order/1234'.
Retrying validation with reduced path: '/v3/store/order/1234'] (2/5)
No API path found that matches request '/v3/store/order/1234'.
Retrying validation with reduced path: '/store/order/1234'] (3/5)
# This time the path is found in the API-Specification and the validation is finally performed
To improve the performance, the given original path mapped to the API-Specificaion path found in the API-Specification is internally cached. /api/petstore/v3/store/order/78787 --> /store/order/1234. This cache is limited to 1000 entries.
You can adjust the size of this cache from the script code: validator.getExposurePath2SpecifiedPathMap().setMaxSize(5000);
When the validator is called like so:
the given path might contain the entire path as it is exposed on the API-Gateway. But, the path is used to lookup the schema as defined in API-Specification and obviously it fails, when the path includes the customer specific exposure path.
For example when the Petstore is exposed on the API-Manager customers might configure them with a different exposure path:
/api/petstore/v3
.At runtime, a number of variables contain the API-Path, but all of them include the Frontend-API exposure path. For instance:
/api/petstore/v3/store/order/123456
.To simplify the use of this plugin, the validator should support such a path, even if it contains the frontend API Exposure path.
This should eliminate the need to manipulate the path variable in the scripting code and thus complicate the code unnecessarily.
The text was updated successfully, but these errors were encountered: