Is it possible to generate OpenAPI schema for path...

# http4k

[Mikael Ståldal]

Is it possible to generate OpenAPI schema for path parameters? I can get the validation with Path.regex("([0-9a-fA-F])") now, but the generated schema is just:

{
            "schema": {
              "type": "string"
            },
            "in": "path",
            "name": "hexParam",
            "required": true,
            "description": "Hexadecimal value"
          },

I would like:

{
            "schema": {
              "type": "string",
              "pattern": "[0-9a-fA-F]"
            },
            "in": "path",
            "name": "hexParam",
            "required": true,
            "description": "Hexadecimal value"
          },

[dave]

unfortunately all Path parameters are created without the pattern metadata. you can mapWithNewMeta to change the type though

[dave]

(it's a limitation of the model used)

[Mikael Ståldal]

Any plans to fix this?

[dave]

"fix". no

[dave]

it would require a significant rewrite of the existing system. So also no.

[dave]

🙂

[dave]

There are several limitations of the system in http4k, but they are categorically not bugs. They are limitations. 😉

[Mikael Ståldal]

OK, fair enough.

[Mikael Ståldal]

But then it seems like http4k-contract is not sufficient for my OpenAPI generation needs.

[dave]

Well there are nice tooling things you can do with the contracts, but if you really aren't going to use them then the standard routing is an excellent option tbh

[Mikael Ståldal]

I don't have need for standard authentication, callbacks or webhooks either.

[Mikael Ståldal]

So I'll try standard routing instead.

[Andrew O'Hara]

Even if I'm not using the OpenApi generator, it's still nice because:
• you get the path parameter values injected into your server handlers
• you can reuse the ContractRouteSpecX.Binder for your clients and fakes
• Even if you don't expose the spec publicly, it's still incredibly useful for documenting internal APIs