Menu json response is not jsonapi
[development@localhost ~/P/bolt-test] (master) http http://localhost:17000/json/menu
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Cache-Control: no-cache
Connection: keep-alive
Content-Type: application/vnd.api+json
Date: Thu, 25 May 2017 10:54:12 GMT
Server: nginx/1.13.0
Transfer-Encoding: chunked
X-Debug-Token: 4fb78b
{
"data": {
"main": [
{
"label": "Home",
"title": "This is the first menu item.",
"path": "homepage",
"class": "first"
},
{
"label": "Second item",
"path": "entry\/1",
"submenu": [
{
"label": "Sub 1",
"path": "entry\/2"
},
{
"label": "Sub 2",
"class": "menu-item-class",
"path": "entry\/3"
},
{
"label": "Sub 3",
"path": "entry\/4"
},
{
"label": "Sub 4",
"class": "sub-class",
"path": "page\/3"
}
]
},
{
"label": "All pages",
"path": "pages\/"
},
{
"label": "The Bolt site",
"link": "http:\/\/bolt.cm",
"class": "last"
}
]
}
}
What do you mean exactly?
This is indeed outside of the JSONAPI specifications as it's only meant to return the menus defined in menu.yml, nothing else.
What would you want to expect instead?
I would expect everything coming back as a JSONAPI response seeing as the endpoint is within the same namespace as everything else, and the fact the response advertises itself as JSONAPI spec:
Content-Type: application/vnd.api+json
Just to clarify, having arbitrary and unexpected non-JSONAPI responses coming back from the API requires boilerplate code at the client's end in order to handle them.
Ok thanks, that makes sense.
I'll have to think about how those then, as it may potentially break BC. I did not want to add too much stuff to the menu query when I was making it. But I see your point.
Perhaps could return the current response when the client sets accept: application/json and jsonapi when vnd.api+json is requested instead?
Yeah, that seems like a nice idea.