Restricting Delivery API Responses to specific pro...
# help-with-umbraco
p
I have a requirement from the front-end dev team to provide all that is required to populate multi-level site navigation for a large multi-site install. They want to be able to make a request to an endpoint and get back all that is needed to render the navigation for each site. The navigation property is currently defined as a MNTP that allows editors to select the top level nodes. At the moment the API will return all of the top level nodes and their properties but in reality I need to traverse down the tree collecting all descendent nodes (based on criteria e.g. not hidden from navigation, not list items etc) and return those nodes in a structured way. What we don't want is all of the bloat of every single property on every single node also being returned so it would be useful to restrict the responses to specific properties. Yes, the front-end dev could make lots of API calls to do the traversal themselves but that is costly in terms of the number of API calls to be made and also the size of the responses. I also don't believe that responsibility should fall on them. Am I overlooking something that would currently allow me to do this?
s
I'd just do this with an
UmbracoApiController
that returns the exact result that you need. If we had a GraphQL implementation then that would be ideal for this kind of query, but for now, the focus is on enabling people to be able to take property data and stick it into a headless frontend.
p
We were originally going to go down this route before the Content Delivery API was announced but now the Delivery API is available it would be preferable to keep all the API requests consistent so I am currently testing out the feasibility of implementing our own ContentApiControllers that inherit from
ContentApiControllerBase
and extending them where necessary.
> If we had a GraphQL implementation then that would be ideal for this kind of query I agree but my best guess is that you will be keeping this under wraps so that people sign up to Heartcore which wasn't a good fit for the project
s
No it's not about money, it's pretty difficult to make a reliable GraphQL service that doesn't affect the website, all of the GraphQL stuff in Heartcore happens on dedicated servers that are made for that (so it requires a specialized infrastructure setup). I can recommend checking out https://marketplace.umbraco.com/package/nikcio.uheadless as well, looks really cool, but haven't tried it myself yet!
p
Thanks for the clarification, I'll take a look
2 Views