Generalized API for all Geo Replicable Objects

This is based off of @mkozono and my conversations found here: !20672 (comment 253547300)

Problem to solve

• As we continue to add Replicable objects, it becomes a larger problem of creating APIs and keeping them all in-sync
• Additional APIs results in increased complexity on how the frontend communicates with the backend via these APIs
• With our current approach, self-service Geo isn't fully possible without knowledge of creating custom APIs for each new replicable object

Intended users

• Sasha (Software Developer)

Proposal

• Create an API for replicable categories that list available replicable under the category
  • /api/v4/geo/blob - Lists all available "Blob" replicables
  • /api/v4/geo/repository - Lists all available "Repository" replicables
• Create a new Generalized API to promote consistent behavior between all replicable objects within their same category
  • /api/v4/geo/blob/:replicable (For items, like Uploads)
  • /api/v4/geo/repository/:replicable (For repositories, like Projects)
• Use existing APIs (ex. api/v4/geo_replication/designs) as a base of how these new APIs should behave
• Each api should allow for the following actions:
  • GET - Returns an array of everything matching query (Should allow for a status and name as query params)
  • GET/:ID - Returns a single object that matches the id given
  • POST/:ACTION - Runs the requested action on ALL items that are a part of the Replicable Object
  • PUT/:ID/:ACTION - Runs the requested action on the single object that matches the id given
• The API should also support pagination

Potential Flow of the API

Geo_API.pdf

What does success look like, and how can we measure that?

• A MR of the API congruent with the current APIs behind a feature flag
• Follow up MR showcasing the Frontend switching to the new API with same functionality as before
• Follow up MR showcasing the remaining Replicables allowing support for the new API structure