Conversation
4ac9951 to
a0ed996
Compare
|
@WyriHaximus please rebase this on the |
|
@cebe Will rebase and push later tonight 👍 |
|
@cebe Rebased it, is there any specific testing I should add reside from the existing change? |
|
Webhook property check should depend in the openapi Version. Only require webhook in 3.1 and keep old behavior in 3.0. Also would be good to have a WebHookTest which checks basic webhook example |
Done that just now
Doing this tomorrow 👍 |
2176808 to
0df8b5e
Compare
src/spec/OpenApi.php
Outdated
| if ($this->getMajorVersion() === static::VERSION_3_0) { | ||
| $this->requireProperties(['openapi', 'info', 'paths']); | ||
| } else { | ||
| $this->requireProperties(['openapi', 'info'], ['paths', 'webhooks']); |
There was a problem hiding this comment.
I added the testcases for OpenAPI 3.1 here #129 and the OpenAPI Schema says, that only openapi and info is a required field in OpenAPI 3.1
// vendor/oai/openapi-specification-3.1/schemas/v3.1/schema.json
"required": [
"openapi",
"info"
]
// vendor/oai/openapi-specification-3.1/schemas/v3.0/schema.json
"required": [
"openapi",
"info",
"paths"
],
There was a problem hiding this comment.
Interesting, I was expecting to be a oneOf for paths and webhooks: https://github.com/OAI/OpenAPI-Specification/blob/main/schemas/v3.1/schema.json#L56-L72
There was a problem hiding this comment.
yeah you are right. Thats my fault. Then components are also possible and missing in the atLeastOne argument.
Then should the examples with components, hooks and paths should work
There was a problem hiding this comment.
Subscribed to #129 I'll rebase this PR and fix any errors coming up when it gets merged
There was a problem hiding this comment.
here is the text representation of that from the specification:
https://spec.openapis.org/oas/latest.html#openapi-document
The OpenAPI document MUST contain at least one paths field, a components field or a webhooks field.
48586f5 to
f7ecbac
Compare
src/spec/OpenApi.php
Outdated
| 'info' => Info::class, | ||
| 'servers' => [Server::class], | ||
| 'paths' => Paths::class, | ||
| 'webhooks' => WebHooks::class, |
There was a problem hiding this comment.
is there a specific reason why you introduce the "WebHooks" class and not implement this as a map of "string"->"PathItem" as described in the specification?
... ... ... webhooks Map[string, Path Item Object | Reference Object] ] The incoming webhooks that MAY be received as part of this API and that the API consumer MAY choose to implement. Closely related to the callbacks feature, this section describes requests initiated other than by an API call, for example by an out of band registration. The key name is a unique string to refer to each webhook, while the (optionally referenced) Path Item Object describes a request that may be initiated by the API provider and the expected responses. An example is available.
There was a problem hiding this comment.
The WebHooks class is a copy, with some things changed, of the Paths class. Would the alternative just be wrapping a Path::class in an array, like servers?
I'm not better in this, so not judging you ;-) Tests are fine, I just wonder about implementation. I tried to follow the spec quite stricly in which Objects are described. There is a "Paths" object in the spec but no "Webhooks" object, which is not consistent. Need to decide if it's fine for the implementation to break with the strict dependence on the spec or not. |
12da888 to
4e30366
Compare
Just dropped the |
|
Thanks, looks good. |
|
Tests are failing with |
2a5d0c9 to
8c4f36a
Compare
Whoops, want me to squash both commits into one? |
8c4f36a to
0c10bea
Compare
|
Squashed both commits together |
|
Thank you! |
|
No problem, looking forward to having full support in |
No description provided.