support for basePath

[flixr]

support for basePath

[chohmann]

@flixr this is actually working as originally designed. This is documented in the Prism Docs in the 2nd question of the FAQ section.

[flixr]

Thanks, missed that FAQ entry.
But this basically means I can't use that with Swagger/OAS2 for mocking with this prefix... Or am I missing something else?

[chohmann]

Yeah you'd have to build whatever you'd put in the basePath property, into the paths themselves. Alternatively, you can use Prism v2 which should have the functionality you're looking for.

[flixr]

Ok, thanks.
A bit of a shame though...
Would be good if prism would have respected it if the definition loaded is a v2 def... instead of just implicitly always going with the v3 logic.

[displague]

I ran into this problem with an OAS3 spec where the servers block includes a path:

servers:
  - url: https://api.equinix.com/metal/v1

All of the OAS3 paths definitions are relative to that root.

The tools that I want to validate against the proxy know to use /metal/v1. I have to manipulate those tools a good bit to fit the prism pattern. It would be nice for Prism to expose an argument for a base path.

If base-path were an option, this could look like:

prism proxy equinix-openapi3.yaml https://api.equinix.com/metal/v1  --errors --base-path /metal/v1

Without it, the output reports the proxy URLs on a root that doesn't match what tools will expect:

[4:34:17 PM] › [CLI] ℹ  info      PUT        http://127.0.0.1:4010/user

[chohmann]

@displague could you open up a new Github Issue for the issue you're describing?

In the new Github Issue could you include the following information:

• a complete spec that illustrates your issue
• what prism command you ran
• when requesting to http://127.0.0.1:4010/user does prism ultimately forward the request to https://api.equinix.com/metal/v1/user? Or does it forward the request to https://api.equinix.com/user?