|
|
Post by AMI_Mani on Nov 14, 2023 19:29:16 GMT
Hi,
Can we use Redfish-Protocol-Validator tool to validate redfish specification version conformance? Assume service root giving RedfishVersion as 1.19, how it can be verified.
If Redfish-Protocol-Validator passed without any error means , it's compliant to specific redfish version(includes all mandatory features mentioned in 1.19 specification). Unable to see any log related to RedfishVersion details in Redfish-Protocol-Validator report whether it's complaint to 1.19 specification
Thanks,
Mani
|
|
|
|
Post by mraineri on Nov 14, 2023 21:25:07 GMT
There is almost nothing in the protocol that requires version checking today. Everything added in after the fact is a "should" or "may", and doesn't impact requirements when changing the version. To date, there's only one change highlighted in the changelog as a compatibility issue, and this was back in version 1.6.0 when OpenAPI was introduced:
> Added support for the OpenAPI Specification v3.0. This allows OpenAPI-conforming software to access Redfish service implementations. This change might require modification to an implementation to support this version of the specification.
The OpenAPI changes specifically are covered by the Redfish Service Validator. So, with that exception, you can simply change the version number up to version 1.19.0 and still be conformant. We haven't had the need to perform version testing yet due to how we've kept changes backward compatible with older versions of the spec.
|
|
|
|
Post by AMI_Mani on Nov 15, 2023 18:47:48 GMT
Thanks for the details. So if we already supporting 1.6.0 , version can be changed to 1.19.0 without adding any changes in service implementation. Related to OpenAPI , this post redfishforum.com/thread/889/openapi-version-mismatch mention as optional and can implement resource using json schem(any one of three - CSDL, JSON Schema, Openapi) which openapi is also not mandatory for 1.19.0 Thanks, Mani |
|
|
|
Post by mraineri on Nov 15, 2023 21:46:20 GMT
That's correct; everything we added in the spec over time has been either clarifications, fixes, or optional new content. For the new content, there certainly are new "shall" statements in terms of how the new functionality behaves, but they're all conditional based on if you support the function; "If you support 'X', then you shall do 'Y'".
With OpenAPI, you're right in that you do not need to support the OpenAPI schemas themselves. However, supporting OpenAPI from a spec perspective also required normalizing the URI patterns of all resources. So, even if you do not support OpenAPI schemas in your service, you still need to follow the URI patterns we've added. The URI patterns are encoded in all three schema languages.
|
|
