Graph service (enhancements)

[p5150j]

Parent Issue: Refactor and Improve Graph Service Endpoints

As a developer integrating with the Graph service,
I want to refactor the current Graph service endpoints and align them with the graph-sdk conventions,
so that the API is more intuitive, maintainable, and compliant with DSNP standards.

---

Acceptance Criteria

• Review SDK & Node Bridge

  • Review the graph-sdk GitHub repo to understand the expected API contracts and supported methods.
  • Review the Node bridge code to understand how it wraps or interacts with the SDK.
  • Check out https://spec.dsnp.org/ for graph spec

• Evaluate Graph Service Implementation

  • Analyze the current Graph service endpoints and identify inconsistencies (e.g., misuse of HTTP verbs like POST for getGraph).
  • Compare with the SDK API reference: https://projectlibertylabs.github.io/graph-sdk/dsnp_graph_core/api/api/index.html.

• Refactor Endpoint Naming and Methods

  • Rename or restructure endpoints to follow standard REST conventions and SDK practices (e.g., GET /graph instead of POST /getGraph).
  • Maintain backward compatibility where possible or introduce versioned controllers (e.g., /v2/graph) to avoid breaking changes.

• Document Changes

  • Clearly document any breaking changes.
  • Update internal documentation and API references to reflect refactored endpoints.

• Testing & Validation

  • Add integration tests to ensure SDK interactions are correct.
  • Validate that existing consumers are unaffected or informed of version changes.

---

Suggestions

• Get all graphs for a certain MsaId #804
• Do we need direction in existing PUT /v1/graphs ? #805
• Create a new graph update endpoint with better intuitive design #809
• Add an endpoint to force update the graph with latest published key #806
• Ensure PUT /v1/graphs supports private friendships #807
• Add an endpoint to get all broken friendship connections #808

Notes

• Be mindful of breaking changes, especially in shared environments.
• Any new or refactored controller should include versioning (e.g., v1, v2) to maintain backward compatibility.

[prestonzen]

• Any breaking changes make a V2 Graph Service controller instead of updating V1
• Clarify naming convention in the service
• Reference rust graph SDK dependency of how the graph is stored on the Frequency chain for easy API route creation: https://github.com/ProjectLibertyLabs/graph-sdk
• Understanding the overall protocol interaction more https://spec.dsnp.org/

[aramikm]

Some more docs about graph https://docs.google.com/document/d/1EGcIBeelnWF_rD9S99Q_zlgqIzQbUjhtKTei7qwYw28/edit?usp=sharing