Pdns: REST API inconsistencies

[schlitzered]

• Program: Authoritative, REST API
• Issue type: Bug report

Short description

Hey, i am in the middle of implementing a python client library for interacting with pdns, and i noticed some problems:

1:
/api/v1/servers/:server_id/zones
has no type attribute, I guess it should be Zone

2:
should object type "Comment" and "Records" for RRSet have a type attribute?

3:
/api/v1/servers/:server_id/zones
url attribute is missing leading slash '/'

IS:
"url": "api/v1/servers/localhost/zones/example.com."
SHOULD:
"url": "/api/v1/servers/localhost/zones/example.com."

4:
rrset update, should "modified_at" be set by client for comments?

i am not sure if 2&4 are a bug, but it would be nice if you could clarify

Environment

• Operating system: CentOS 7
• Software version: pdns-4.0.3-1pdns.el7.x86_64
• Software source:PowerDNS repository

Steps to reproduce

simply call the REST Resources as described in the documentation

Expected behaviour

please see short description

Actual behaviour

please see short description

[zeha]

1. Maybe. It's not a full Zone object.
2. Could do. Large zones will have their JSON representation seen blown up and the gain is questionable.
3. IIRC this is fixed on master.
4. This is allowed, but optional.

[schlitzered]

Thank you for your answers:

i would like to suggest some changes to the zone related endpoints:

• /api/v1/servers/:server_id/zones should not return records, just like with cryptokeys, they are also not returned here

• create a new endpoint: /api/v1/servers/:server_id/zones/records, which will be used for managing records

• implement pagination/result_limits for at least listing domains, records & cryptokeys, this will improve usability with big zones

• implement sorting for at least by name for domains, records & cryptokeys

i hope this is the right place for a proposal.

BTW: is there a swagger file around for PowerDNS?

[geoff-maddock]

Investigating moving to using the API instead of a database connection to our powerdns instance, but finding the lack of pagination could be blocking. Any movement on this? This is the only issue on the topic I could find and it's pretty stale.

[Habbie]

Hi Geoff, the feature is not planned for 4.4 (which will come out in a few weeks). We haven't decided if it will be a big priority after that, sorry.

[geoff-maddock]

Hi Geoff, the feature is not planned for 4.4 (which will come out in a few weeks). We haven't decided if it will be a big priority after that, sorry.

Thanks for the follow up Habbie. Is there any feature roadmap that is publicly available where I could see any slated API updates?

[Habbie]

The only thing that comes close to a roadmap is milestones on tickets, and this ticket is auth-5 (which means 'we intend to do this someday') because it is a lot of questions in one. If you want a better estimate about pagination, I suggest filing a separate ticket just for pagination. That would also be a good place to discuss actual implementation, which always helps towards getting the code written.