Added rule hasKey

[bottoy]

Added the rule hasKey to verify that the Paths object has ONE pathItem which contains one of the values provided in the rule.

Sample Rule:
"name": "health-check",
"object": "paths",
"enabled": true,
"description": "An health endpoint is required",
"hasKey": ["health", "status"]

So a pathItem with "/dssdhealth" will pass ...

[philsturgeon]

This is a great rule, but I think it could cause a little confusion in its current state. Existing usage of regex is limited to the pattern or notContain rules, both of which suggest that regex (or at least partial matching) is coming.

My concern is that hasKey sounds like its just literally going to look for foo, but would also actually match against foobar. This might be unexpected behavior for other speccy users.

Can we find a name which makes this functionality more clear? hasKeyPattern or something?

[bottoy]

I saw the solution on Github. The use case where we developed this option is to assure that APIs/Swagger we post have a health endpoint. Because we cannot control out-of-the-box swaggers from 3th party suppliers we need to be able to match different endpoints as each supplier has his own name (monitor/health/status ....) Not clear how the regex solution simply can do this ... You can change the name if you like to - no special feelings attached ;-) Op vr 4 jan. 2019 om 15:35 schreef Phil Sturgeon <[email protected]>:

…

This is a great rule, but I think it could cause a little confusion in its current state. Existing usage of regex is limited to the pattern or notContain rules, both of which suggest that regex (or at least partial matching) is coming. My concern is that hasKey sounds like its just literally going to look for foo, but would also actually match against foobar. This might be unexpected behavior for other speccy users. Can we find a name which makes this functionality more clear? hasKeyPattern or something? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#232 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AM4Cc3kUS9Ldq79UlzvMGxRjvhFfoEImks5u_2bAgaJpZM4ZeLXW> .

[philsturgeon]

Whilst I can definitely see the use for this rule, I have a new rule, which is: new rules go into oas-kit :D

We're trying to use their linter instead of maintaining our fork, so no more rule actions in Speccy. #248