Repository navigation
[Feature Request] Option to parse XML from Classic API endpoints #33
Description
Currently, JSON responses are requested from the Classic API and can be parsed with the .json() method:
response = api.classic_api_request("GET", "accounts/userid/257")
user_info = response.json()However, there's no equivalent option for parsing XML responses if the headers are overridden to request XML:
response = api.classic_api_request("GET", "accounts/userid/257", override_headers={"Accept": "application/xml"})
user_info = response.xml() # this doesn't existSome 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.
Activity
[-][Feature Request] Option to accept XML from Classic API endpoints[/-][+][Feature Request] Option to parse XML from Classic API endpoints[/+]brysontyrrell commentedon Nov 28, 2023
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 -> dictor do we want to return an object likeElementTree?homebysix commentedon Nov 28, 2023
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.
brysontyrrell commentedon Jan 5, 2024
@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 aredicts and others arearrays.Here's an issue that describes it well: martinblech/xmltodict#14
liquidz00 commentedon May 16, 2025
@homebysix Given the issues with XML conversion to dictionaries/lists, would an
.xml()method returning anElementTreeobject still be of use? I don't think its a bad idea and certainly see the value in offering flexibility.Admittedly though, it feels to me as though the Pro API is becoming the default over the Classic API as more classic endpoints are being deprecated/moved to the Pro environment. Curious as to your thoughts.