magicdgs-gaming / ygoprodeck-openapi Goto Github PK

For atk/def/level (and maybe others), a pattern can be provided so the parameter match one of the two:

• Operator (lt, lte, etc.) + number
• number only

The following schemas are not documented in the original site and serialization might fail (e.g., in postman, the backup branch with all enum schemas generate warnings when imported). This will produce problems when generating client code as it might throw exceptions when deserializing.

To be consitent, the enums will be removed from those places. It is better that the client code removes those hard-coded enums even if failure is possible, because otherwise they might be to restrictive and new API being released everytime that something is introduced without any information.

The following enums are commented out from the API schemas:

• schemas/Format.yaml - found that not all formats are documented (before having the enum)
• schemas/Race.yaml - found that not all races are documented
• schemas/Type.yaml - possibility that the types are not well documented
• schemas/FrameType.yaml - possibility that the frametypes are not well documented

Maybe the solution will be to request endpoints for available values, similar to the /archetypes.php endpoint.

Not sure if this is possible with OAS 3.0, but otherwise it is a bit inconsistent.

We are currently pre-releasing on every push of a tag with the Automatic Releases action. When we consider that the definition is ready to be released (or we decide on the schema for versioning), we should do proper releases with the GH Release action.

Currently the tests implemented are only against required ones, but we should provide some more newman/postman tests to check if we are in sync with the API.

The language parameter is something that I have not documented yet cause I am not going to use. But for completeness I would like to add, as client-derived code might use it.

The Card schema differs between types or cards, some containing some values and others a different one. Using inheritance with discriminator (anyOf?) should be evaluated.

Card images are based on IDs (which are numeric) and set images are based on the set_code, which is a string.

This will be nice for a better understanding of the API and it is supported by OAS 3.0 (see https://swagger.io/docs/specification/links/). For example:

• card.id is linked to the /images endpoint
• /archetypes.php endpoint provides the valid values for the archetype parameter on the /cardinfo.php endpoint
• /cardsetsinfo.php setcode parameter links to the card.card_sets.setcode from the /cardinfo.php response

Add a github action to publish both releases and latest snapshot, and also to check if the PRs does not break the definition.