...
Code Block | ||||
---|---|---|---|---|
| ||||
components: parameters: PolicyId: name: policyId in: path required: true schema: type: string paths: /policies/{policyId}: get: parameters: - $ref: '#/components/parameters/PolicyId' |
Schema Usage in Paths
Schema | Count | Paths |
---|---|---|
ErrorInformation | 4 | /policies/{policyId} , /policytypes/{policyTypeId}/policies , /policytypes/{policyTypeId}/policies/{policyId} , /policytypes/{policyTypeId}/policies/{policyId}/status |
JsonSchema | 2 | /policytypes/{policyTypeId}/policies , /policytypes/{policyTypeId}/policies/{policyId} |
NearRtRicId | 3 | /policies , /policies/{policyId} , /policytypes/{policyTypeId}/policies |
NotificationDestination | 1 | /policies/{policyId} |
PolicyId | 3 | /policies , /policies/{policyId} , /policytypes/{policyTypeId}/policies |
PolicyInformation | 2 | /policies/{policyId} , /policytypes/{policyTypeId}/policies/{policyId} |
PolicyObjectInformation | 1 | /policytypes/{policyTypeId}/policies/{policyId}/status |
PolicyStatusObject | 2 | /policies/{policyId} , /policytypes/{policyTypeId}/policies/{policyId}/status |
PolicyTypeId | 3 | /policytypes/{policyTypeId}/policies , /policytypes/{policyTypeId}/policies/{policyId} , /policytypes/{policyTypeId}/policies/{policyId}/status |
PolicyTypeInformation | 2 | /policytypes/{policyTypeId}/policies , /policytypes/{policyTypeId}/policies/{policyId} |
PolicyTypeObject | 1 |
|
Using allOf to Extend Objects
To avoid using the `required` flag directly and create more flexible schemas, we can use the allOf keyword to combine schemas. This allows you to create an extended schema from an original one without repeating required properties.
https://openapi-generator.tech/docs/generators/spring/#schema-support-feature | |||||||||
---|---|---|---|---|---|---|---|---|---|
From the documentation of the openapi generator used in A1PMS, AllOf is not supported for spring server generator. But it still generated objects without the use of extending the parent class. For example: | |||||||||
An extended object in the specification yaml:
| |||||||||
| |||||||||
...
TODO and topic to follow
- Evaluate the necessity of optional fields: Determine if certain optional fields can be removed or if their use can be better documented to avoid dead data.
- Consider adopting more specific schemas for critical operations: This can improve both the documentation and the generated code quality.
- Prepare for code adaptations: Implement patterns like Adapter/Builder/Transformer to handle translations between similar objects, facilitating easier maintenance and adaptation to specification changes.
- Regular compliance checks: Ensure regular checks against ORAN specifications to stay compliant and make necessary adjustments in a timely manner.
- Adopt Specific Schemas: Use specific schemas for different API operations to improve clarity and reduce the risk of errors.
- Implement Adapter Pattern: Use the Adapter pattern to manage differences between similar objects, ensuring compliance with ORAN specifications.
- Leverage OpenAPI Features: Use OpenAPI's advanced features like `allOf`, `oneOf`, `anyOf`, and discriminators to create flexible and reusable components.
...