Leading slash rule?

[szrudi]

Hey!

I have an OpenApi v3.1 yaml, and recently I made a mistake of removing a leading slash from one endpoint.

The issue I saw in swagger-ui:

We can say that this is a swagger-ui problem, but it got me thinking. Why did vacuum not catch this?

There is a rule to check for extra trailing slashes:
https://quobix.com/vacuum/rules/operations/path-keys-no-trailing-slash/

And the specs do say there should be a leading slash:
https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.1.0.md#paths-object

So am I missing something? Should there be a rule for this?

PS. I've checked a lot of tools when deciding on the linter to integrate and vacuum turned out to be awesome, thanks for this great and fast tool!

[LasneF]

hello @szrudi can you clarify your statement ?

meaning in your API spec do you mention path like this

/a/b
or
/a/b/

can you provide the faulty spec

according to good practices this should be /a/b
when you mentionned :

And the specs do say there should be a leading slash:

in fact i think it goes the otherway round , meaning that there should not be a trailing /
if you look at any example in the OAS repo all of the is following /a/b

[szrudi]

Hey @LasneF thanks for the quick reply!

The trailing slash rule works fine, I'm talking about leading slashes.

Here is a simplified example:
public-api-docs.json

And a loom to show the issue: https://www.loom.com/share/b60ea9d05067426a8c862e1de3ab52dc

I see two issues here:

• swagger-ui behaves in a strange way when there is no leading slash, parameter details disappear.
  This is irrelevant here as it is a swagger-ui issue.
• vacuum does not warn me about a missing leading slash even though it is required by OpenApi specs:

A relative path to an individual endpoint. The field name MUST begin with a forward slash (/).

[szrudi]

@LasneF @daveshanley What do you think? Is this a missing rule that would be good to have?

[LasneF]

sorry for the confusion leading , trailing , and ❤️ the video, this make it so clear ,
not sure what version of swager ui you are using but with latest version it is displayed correctly

notice as well the fact that ... it is mentionned as an invalid spec

that what you reference in the OAS spec is 100% valid , so it is clearly a bug => i created a ticket #524

@daveshanley this should be fixed by leveraging simple regular expression knowing that under path , properties must starts by either / for part or by X for extension