[TO-DO] Athena Navigation endpoint about capiv2-strapi HOT 16 OPEN

What I have in mind is something like this:

Right now doing a curl on the API root gives the website

Instead of giving the website, one can instead return a list of supported endpoints with some special properties which would indicate if that endpoint should be displayed in Athena. One can do both a website and JSON output using the accepts header or one can place the website in the root and the apis can start from https://api.canonn.tech/api/

from capiv2-strapi.

Athena itself will run on https://canonn.tech the api itself will be on https://api.canonn.tech this is mainly due to limitations of Strapi not having a prefix option (it used to but was too broken so they removed it)

Until they re-add prefixes I can't do sub folder based proxying in Nginx, hence the split. Most likely what I will is create a model like navigation to allow us to use the Strapi Admin panel to edit this in production as Strapi is node based meaning all changes to the file system also required node to restart meaning I could knock my production API offline to update (even though in this case it would be a few milliseconds)

from capiv2-strapi.

I may place it on athena-navigation in case we have any other specific Athena endpoints to create

from capiv2-strapi.

That would be fine too.

from capiv2-strapi.

All I need to know is what the structure needs to look like @SayakMukhopadhyay I can customize the response structure no matter how I build the model.

Structure and fields required is all I need

from capiv2-strapi.

Right now, to start I need a few keys. So the structure of the response could be as such

[{
   endpoint: '<some way to denote the endpoint url>',
   title: '<some user friendly title for the endpoint>',
   athena: true|false
}, 
{...},
...
]

from capiv2-strapi.

I take it for nested menus we also need a parent/child relationship yeah?

from capiv2-strapi.

Yeah, but I dont see where a nested menu would be feasible. I think all endpoints can be there own navigation element.

Or, instead of nested elements in the left hand nav bar, one can use tabs.

from capiv2-strapi.

Tabs would also work too

from capiv2-strapi.

In that case, having a children key would suffice.

from capiv2-strapi.

with the children just being an array of what specifically say types like: ["ap", "bm", "cs", ... ]

(Thinking in terms of apreports, bmreports, csreports to construct the api queries)

Or an array of objects that lists out the short code and full title of the tab

from capiv2-strapi.

An array of objects should be the way to go. One can flatten it if needed.

from capiv2-strapi.

Alright that is what I shall do then. I'll get to work building the navigation model here this weekend

from capiv2-strapi.

(I'll push it into our development server https://api.canonn.tech:2083)

from capiv2-strapi.

So here is the example structure based on the model I created:

[
    {
        "id": 1,
        "title": "Dashboard",
        "endpoint": "/",
        "enabled": true,
        "tabs": [
            {
                "id": 1,
                "title": "Test Tab",
                "code": "test"
            }
        ]
    }
]

from capiv2-strapi.

Dashboard is the root page in the website right? That would mean that its content would be different than that of the different sites right? In that case I think we should only have the sites in that response.
Also the structure itself looks good but got a couple of questions:

1. What is enabled
2. What is code and why doesn't the inner object have enabled and outer object doesnt have code?

from capiv2-strapi.