LINK TO MOCK-UPS

Look at mock-up user flows to start sketching up APIs, focused on roles + bindings and the new access flows

 
This spike will focus on sketching up APIs for Roles, Groups and RoleBindings (and anything else needed based on the mocks), specifically driven by mock-up user flows and new access flows within the Kessel v2 user experience. This effort is integral to the broader initiative to establish RBAC v2 APIs and data models, aiming to deprecate v1 endpoints, reduce long-term complexity, and integrate RBAC into the proper Kessel project, while also enabling new features required to support the v2 experience. The design of these APIs will be a collaborative working document between Kessel RBAC engineers and the platform experience team. The output will outline proposed API contracts and operations. 
 
Goals of this Spike:

• Translate mock-up user flows and new access flows into concrete API sketches and preliminary contracts for Roles, Groups and RoleBindings, defining necessary endpoints, operations, and interactions.
• Ensure the API designs enable the addition of new features and functionality required to support the v2 experience.
• Confirm that the API design for Roles supports specific user flow requirements such as viewing workspaces for a role and filtering on description.
• Propose API designs that are consistent with established patterns like pagination
• Lay the essential groundwork for the V2 API specification at /v2/openapi.v2.yaml, outlining its structure and key endpoints.

 
Key Deliverables/Outputs:
1. Preliminary API Design Sketches and Contracts: Detailed outlines of proposed API endpoints (e.g., GET /api/rbac/v2/roles/, GET /api/rbac/v2/roles/<uuid>/, and corresponding RoleBinding and new access flow endpoints), including considerations for query parameters, request bodies, and response structures, explicitly mapped to user flow scenarios.
2. User Flow-to-API Mapping Documentation: A clear document illustrating how specific user interactions and new access flows map to the proposed V2 API calls and their expected responses, highlighting the "why" behind each API design decision.