routes no longer work for me in version 1.12

[gaiederer]

info:
  version: GIT_TAG_GOES_HERE
  title: api-missions
servers:
  - url: /api/v2/missions
    description: Available service
paths:
  /platforms:
    get:
      description: returns all the Platforms known to the system.
      x-mojo-to: {"controller": "controller-platform", "action": "rest_list"}
      responses:
        '200':
          $ref: "#/components/responses/platformsResponseSuccess"
        '400':
          $ref: "../api-common/openapi.yaml#/components/responses/responseNotValid"
  /platforms/{platformId}:
    get:
      description: returns the specified Platform.
      x-mojo-to: {"controller": "controller-platform", "action": "rest_show"}
      parameters:
        - $ref: "#/components/parameters/platformId"
      responses:
        '200':
          $ref: "#/components/responses/platformsResponseSuccess"
        '400':
          $ref: "../api-common/openapi.yaml#/components/responses/responseNotValid"
components:
  parameters:
    platformId:
      name: platformId
      in: path
      description: name of an instrument's platform
      required: true
      schema:
        type: string

OpenAPI version 1.12 loads and validates the spec, but seems to load no routes. I always get back 404. In Version 1.11 routes worked fine. The url for the above paths would look something like

• http://localhost/api/v2/missions/platforms

which would return a list of all platforms, or

• http://localhost/api/v2/missions/platforms/AM1M

which returns info about the specific platform.

The version 3 of the Swagger spec does not seem to support "basepath" any longer. Perhaps this is the issue?

[augensalat]

I would agree that the current (1.12) implementation is wrong.

Assume your Mojo OpenAPI application has a /foo resource. In your OpenAPI3 spec.yaml /servers/0/url is /. "GET /foo" works when you run your application alone.

Now you deploy the API application. In production the API is mounted under /api. Example config for Apache/FastCGI:

ScriptAlias /api /var/www/my_app/script/my_app.fcgi
<Location /api>
    SetHandler fcgid-script
    Options ExecCGI
    Require all granted
</Location>

Of course in your OpenAPI3 spec.yaml /servers/0/url has to be /api now. M:P:OpenAPI parses the OpenAPI3 yaml file, finds /servers/0/url(1) and moves all API-routes under /api:

script/my_app routes
/api                                     *        api
  +/                                     GET
  +/foo                                  GET      "get_foo"

So the API application would expect the request under "GET /api/foo".

Good? NOOO!

Because Mojo::Message::Request does right the opposite. To let the API application be deployment-agnostic Mojo::Message::Request removes the SCRIPT_NAME(2) ("/api") from the REQUEST_URI(2) ("/api/foo"), hence what the application router actually sees is GET /foo.

My understanding is that the problem is in the two lines at https://github.com/jhthorsen/mojolicious-plugin-openapi/blob/master/lib/Mojolicious/Plugin/OpenAPI.pm#L167 The plugin must not move the application routes under $base_path.

WDYT?

(1) This implementation is limited/incomplete of course (2) SCRIPT_NAME and REQUEST_URI are CGI/PSGI environment variables, and also handled by Mojolicious.

[jhthorsen]

@gaiederer: I don't understand how this can be true. I tried changing /servers/0/url in t/v3.t to just "/api/v2/missions" and also change the tests from /v1/pets?limit=10 to /api/v2/missions/pets?limit=10 and they all run successful with version 2.12.

Can you provide a test case, where v3.t (or make a new test) fails?

Also, v3 does indeed support basePath, but it's moved to /servers/0/url.

@augensalat: I think your problem is entirely different. I believe you need something like https://metacpan.org/pod/Mojolicious::Plugin::RequestBase to make sure your mojo application understand that it's indeed served from /api/whatever and not just /whatever. It could also be that this is a completely new issue, where M::P::OpenAPI need to be aware of $c->req->url->base. If that is the case, then please open a new issue for that. I'm 99.9999% sure that what you're talking about does not work with v2 either.

[augensalat]

@augensalat: I think your problem is entirely different. I believe you need something like https://metacpan.org/pod/Mojolicious::Plugin::RequestBase to make sure your mojo application understand that it's indeed served from /api/whatever and not just /whatever. It could also be that this is a completely new issue, where M::P::OpenAPI need to be aware of $c->req->url->base. If that is the case, then please open a new issue for that. I'm 99.9999% sure that what you're talking about does not work with v2 either.

Perhaps my case is different from gaiederer's, and I agree that the basePath issue is the same with v2. Will open an own issue as desired.

[augensalat]

Will open an own issue as desired.

116

[gaiederer]

I did guess about the cause of my issue, and that might be misleading, since I'm no expert here.

But, I did just rebuild everything from scratch, and I still get the same problem -- no routes at all get triggered from my openapi.yaml spec when using version 2.12 of OpenAPI, whereas 2.11 works fine, and all my routes get sent to the appropriate handlers in the appropriate controllers.

I will try and come up with a small test case that I can include here.

[plk]

@gaiederer - this is exactly the problem I had with the attempt to update to v3 on 2.12. I couldn't find the root of the issue but I haven't had time to dig into it.

[jhthorsen]

Please ask google how to configure your reverse proxy correctly and also do look at the modules I linked to.

@augensalat: Also, please do not write things like "Good? NOOO!", since there's so much emotions attached to such an expression which makes the whole comment hard for me to work with.

This answer also applies to #116

[jhthorsen]

Again, for reference:

• https://metacpan.org/pod/Mojolicious::Plugin::RequestBase
• https://mojolicious.org/perldoc/Mojolicious/Guides/Cookbook#Reverse-proxy
• https://mojolicious.org/perldoc/Mojolicious/Guides/Cookbook <-- Look for more cookbooks for your server there.