Convert AirlineCodeLookUp to OpenAPI 3.0 spec

[jordan-gillard]

This PR converts spec/yaml/AirlineCodeLookUp_v1_swagger_specification.yaml from the Swagger 2.0 spec to OpenAPI 3.0. This change was done by:

• converting the file automatically on https://editor.swagger.io/
• reformatting Markdown tables, since the auto converter butchers them
• refactored some of the duplicated fields between component/schemas and component/responses introduced by Swagger's converter.

I then validated spec files with jbang OASValidator.java oasv-1a4dev-config.properties spec and asserted that everything is correct in the web UI.

If this is something the repo maintainers would like done for other files still using the Swagger 2.0 specification, please let me know.

[tsolakoua]

Thanks for your contribution @jordan-gillard. We will review the PR in the next few days!

[gimperial]

Hello @jordan-gillard ,
Thanks a lot for your help in migrating the API documentation.
I noticed one issue with 200 response example. Data is an array in the model but an object in the example.
Can you also explain to me the benefits of the uriType? It looks to add complexity in the documentation just for strings and this is the main change from the previous version.
Thanks in advance

[jordan-gillard]

@gimperial

I noticed one issue with 200 response example. Data is an array in the model but an object in the example.

My bad! Fixed here 3daa9ac

Can you also explain to me the benefits of the uriType? It looks to add complexity in the documentation just for strings and this is the main change from the previous version.

I reverted this change here: dabe43e

My reasoning was that it seemed redundant to specify the same type/format/example repeatedly for each property. But I agree it's nitpicky and really a matter of taste.

Code comparison

          properties:
            self:
-             type: string
-             format: uri
-             example: https://test.api.amadeus.com/v1/area/resources?...
+             $ref: '#/components/schemas/Uri'
            next:
-             type: string
-             format: uri
-             example: https://test.api.amadeus.com/v1/area/resources?...
+             $ref: '#/components/schemas/Uri'
            previous:
-             type: string
-             format: uri
-             example: https://test.api.amadeus.com/v1/area/resources?...
+             $ref: '#/components/schemas/Uri'
            last:
-             type: string
-             format: uri
-             example: https://test.api.amadeus.com/v1/area/resources?...
+             $ref: '#/components/schemas/Uri'
            first:
-             type: string
-             format: uri
-             example: https://test.api.amadeus.com/v1/area/resources?...
+             $ref: '#/components/schemas/Uri'
            up:
-             type: string
-             format: uri
-             example: https://test.api.amadeus.com/v1/area/resources?...
+             $ref: '#/components/schemas/Uri'

Not really related, but one thing I notice is that Collection_Meta is identical across 14 files. Collection_Meta (and some other types) can be written once and shared between schema files once each schema is OpenAPI 3.0 compliant.

[gimperial]

Thanks @jordan-gillard for your updates.
The PR is all good for me.

Regarding your point about Collection_Meta, I totally agree. We have a lot more object that should be common along most of our API but that's not reflecting well, like Error, Warning, ... . We will work on improving over time while migrating to OAS3.
Thanks again for your contribution.