There is GET /dns/:serviceName/:longName to get info about the content of the root folder of a service
There is GET /dns/:serviceName/:longName/:filePath to get the content of a file of a service
There isn’t GET /dns/:serviceName/:longName/:folderPath to get info about the content of a subfolder of a service
This is annoying because if you don’t know the exact path to the file, you cannot discover it
Thanks @BlueMagma. Have raised this as an issue in github. Will try to get this addressed soon.
Ah… that’s good to see. I wondered it was a feature! 
Similar perhaps: If the intention is that everything is discoverable, should a more raw GET /dns/ list all available PublicIDs?
I didn’t test it, but in theory it should be possible to get the content of any subdirectory returned by GET /dns/:serviceName/:longName with NFS API (GET /nfs/directory/:rootPath/:directoryPath).
If what I just said is true, then a new entry point should not be added to the API because it would be a redundant one. Explicitly composing 2 existing entry points keeps API simple.
Thank you.
Well it is only possible if the service is yours, if you are trying to get info on the service of someone else you can’t.
I wondered it could be deliberate, with the thought of allowing some control to the owner of what is visible. In the absence of a server side .htaccess file, it would allow obscuring of certain background content. Still, if a file is accessible if correctly addressed, it falls to the notion of security through obscurity… though would work if a file was bitcoinprivateaddress type length and complex.
I agree with that. As the folders are public, the information is accessible in rust with an unregistered client. So I think it is best to expose it clearly in launcher.
A question was: which API: DNS or NFS?
@BlueMagma gave the answer: GET stuff of DNS API is about reading info of other people, so appropriate place is here and I finally agree with the issue raised by @Krishna.