Open homebysix opened 12 months ago
I'm in favor of this as an option for the Classic API.
No implementation is likely to match the existing Classic API models as those are based on the JSON responses.
The question becomes do we want a conversion function that parses xml -> dict
or do we want to return an object like ElementTree
?
Personally, I'd rather have the dictionary than the ElementTree — lower learning curve and easier to switch between JSON and XML represented objects as needed.
@homebysix Have been looking into XML option with auto conversion to a Python dictionary and there are some issues trying to leverage options like xmltodict
. In a nutshell, the parsers don't know when a node that has only one child is supposed to be an array. You can end up with returns where some resource attributes are dict
s and others are array
s.
Here's an issue that describes it well: https://github.com/martinblech/xmltodict/issues/14
Currently, JSON responses are requested from the Classic API and can be parsed with the
.json()
method:However, there's no equivalent option for parsing XML responses if the headers are overridden to request XML:
Some orgs may benefit from the ability to choose between XML and JSON responses. One use case would be working around Jamf product issues that affect the accuracy of information returned via one format — like
PI104345: /accounts endpoint giving different results when searching by userid vs. username
.Proposal
The SDK could provide an
.xml()
method similar to the existing.json()
method that converts XML responses to dictionary form, possibly leveraging a module like xmltodict to do the work behind the scenes.Alternatively, the response could contain a
.data
attribute that provides the relevant information in structured data (lists or dicts) regardless of what serialization format was requested — a parsed equivalent to.text
. This attribute could replace both.json()
and.xml()
functionalities.Thanks for considering.