API Versioning for registratin part 2

[dleard]

We are going to need to version our API in order to allow us to make changes necessary for registration part 2 to endpoints used in our current version without breaking anything.

We need to define a structure that we think will work best for this. Suggestions: registration/api/v2/...(all object directories ie: operator)/files <- This structure is most likely the way we go registration/api/operator/v2/...(all files)

Strategy suggestion:

• Registration part 2 uses the v1 api
• If a change to an endpoint or its logic is necessary for part 2, create a v2 for that endpoint following the structure we decide upon & use that endpoint for v2

AC:

• [ ] A structure is decided upon for versioning the api
• [ ] A strategy (when to version) is decided upon
• [ ] Documentation is added to the repo on how and when to version the API

[dleard]

@pbastia @Sepehr-Sobhani Have any thoughts on this card?

[Sepehr-Sobhani]

related Django-Ninja docs: https://django-ninja.dev/guides/versioning/

[pbastia]

Summary of May 7th discussion:

• An API v2 can be created by using the existing router and extending it

• Django ninja will expose it on a different route

• The underlying services can be either extended to support both API needs, or we can create multiple services (e.g. OperatorServiceWithoutAddressSupport and OperatorService) with different interfaces that the API versions would talk to

cc @patriciarussellCAS

[patrickisaac]

Notes:

• Spike ticket has been created #1628 and results from that work will determine how to move forward with this current ticket.

[patrickisaac]

Closing this ticket. This has been implemented in the spike #1647