DNS API feedback/comments

I’m taking a look at the DNS API and I think it’s not uniform, specially if I think of the standard/basic rules of RESTful interfaces where the URI identifies the resource the verb is to act on.

If I think about the hierarchy of the resources the DNS defines (or the type of relationship among them), my understanding is that a user owns a longname (can he/she own more than one?), a longname can in turn contain many services, and each service is mapped to a public folder.

Looking at the DNS API, in order to create a longname you send a POST request using the URI corresponding to the “longname” resource you want to create, i.e. /dns/:longName. Now if you want to create/add a “service” resource, the URI doesn’t contain the resource id/name in it, it doesn’t even contain the “longname” resource id/name, both the longname and service names are part of the body of the POST/PUT request.

Also, looking at the URI of the API to get the home directory associated with a service, i.e. GET /dns/:serviceName/:longName, it gives the idea that the hierarchy of the resources is inverted.
I’m guessing the reason behind this is to try to match how a normal URL on the web looks like, but I don’t think that really needs to match the way the safenet resources are accessed thru an API.

4 Likes

Thanks for your thoughts and input @bochaco. You are making some valid points. Over the next weeks, we want to look at the API again and raise a few RFCs to improve it. We will take these things into account for that!

3 Likes

The difference obviously centres on that normal urls are [domain.toplevel] rather than just PublicID.

A more rational ISO like cascade, would empower users with a choice of the categories they want their PublicID to own - or not. I wonder there would be option to have site directly under the PublicID or with a category, as PublicID.cat.website… but does PublicID.cat.website function the same?.. I would expect API request for PublicID.cat.website/ should get index JSON returned in the same way as it does for PublicID.website/ but it seems atm to get InvalidPath error instead.

The clearweb on reflection, rather prefers the toplevel domains ownership of sites, requiring all users choose a master - registering one domain to .biz; and one to .name; etc.

But the reasons for that format are arbitrary and just geopolitical. You could write the “domains” the other way around, for the network it doesn’t make any difference. You could also add service-categories. Neither of those really matter as format you show it with it decoupled from its actual meaning on SAFE (unline in clearnet, where ‘.com’ is organised by one central agency and so forth). So you could already today have browser that shows and understands the URLs differently. As long as it maps them right to the longname, servicename pattern, it doesn’t matter.