The wiki pages should form a network. For now, it can be kept very simple. Gradually, when we know more about the structure of the network (from discussions with the experts), more constraints might come.
Right now, the network can be modeled as an unweighted and undirected graph without self-loops. The backend system does not need to be able to perform heavy graph operations, so a simple table in the relational database should suffice. I suggest a table related_to with two columns to represent an edge. (In the future, more information (weights, edge types etc.) might be added to the edges.)
The list of connected pages should not be provided by the GET /wiki API but only by a new endpoint that returns data about a single wiki page:
The wiki pages should form a network. For now, it can be kept very simple. Gradually, when we know more about the structure of the network (from discussions with the experts), more constraints might come.
Right now, the network can be modeled as an unweighted and undirected graph without self-loops. The backend system does not need to be able to perform heavy graph operations, so a simple table in the relational database should suffice. I suggest a table
related_to
with two columns to represent an edge. (In the future, more information (weights, edge types etc.) might be added to the edges.)The list of connected pages should not be provided by the
GET /wiki
API but only by a new endpoint that returns data about a single wiki page:Request:
Response:
Status code 200: