Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unified Data Model for API Calls Using URN Format #861

Open
tolgaOzen opened this issue Nov 22, 2023 · 0 comments
Open

Unified Data Model for API Calls Using URN Format #861

tolgaOzen opened this issue Nov 22, 2023 · 0 comments
Labels
area/services Issues related with api services and functionalities. iteration Improvement on an existing feature

Comments

@tolgaOzen
Copy link
Member

Issue Overview

We currently have two separate data models for API calls related to relationships and permissions. This leads to minor code duplication, as two different data types/interfaces are needed for JSON serialization.

Proposed Enhancement

I suggest adopting a unified data model that utilizes a URN (Uniform Resource Name) format. This approach can streamline API calls and reduce the redundancy in our code.

Current Approach:

  • Separate models for relationship-related and permission-related API calls.
  • Requires defining multiple data types/interfaces for similar structures.

Suggested Data Model:

  • A single, generic data model using a URN format.
  • Example:
    • entity: {}
    • type: "urn:relation:parent" or "urn:permission:edit" (replacing separate relationship and permission types)
    • subject: {}

Benefits of the Proposed Change

  • Code Simplification: Reduces the need for multiple data type definitions, leading to cleaner and more maintainable code.
  • Enhanced Flexibility: The URN format allows for more descriptive and context-rich identifiers.
  • Scalability: Easier to extend and modify for future API requirements.

Impact on Current System

  • This change will primarily affect how we structure API calls and data serialization.
  • It will require a review and possible refactoring of existing API endpoints and data handling methods.
@tolgaOzen tolgaOzen added iteration Improvement on an existing feature area/services Issues related with api services and functionalities. labels Nov 22, 2023
@EgeAytin EgeAytin moved this to Q4 2023 – Oct-Dec in Public Roadmap Nov 22, 2023
@EgeAytin EgeAytin moved this from Q4 2023 – Oct-Dec to Q1 2023 – Jan-Mar in Public Roadmap Jan 11, 2024
@EgeAytin EgeAytin moved this from Q1 2023 – Jan-Mar to Q1 2024 – Jan-Mar in Public Roadmap Jan 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/services Issues related with api services and functionalities. iteration Improvement on an existing feature
Projects
Status: Q1 2024 – Jan-Mar
Development

No branches or pull requests

1 participant