I just started playing with the API recently so I could make reporting/automation scripts easier, but every time I use it to GET (with Curl on a ubuntu box if that matters) an advanced search group I made, I get a long single line string if I use the default (XML) and if I try JSON, there is a giant multiline header and then again, a giant single line string that would be normal JSON if it where actually spaced. Because of the output I can't parse anything effectively.
What am I doing wrong?
Side note, can we really not export data as a CSV from the API even though we can get it from the GUI?
Yes, you get a long string of XML (or JSON) by default. To get the output printed out in a nice format, for XML pipe the output through
curl -H "Accept: application/xml" -su "username:password" https://your.jamf.pro.url:8443/JSSResource/computers | xmllint --format -
If using JSON, you can use python's
json.tool to do the same thing. Example:
curl -H "Accept: application/xml" -su "username:password" https://your.jamf.pro.url:8443/JSSResource/computers | python -m json.tool
Edit: Regarding your second question, yes, it's currently not possible to get data from the API directly as a csv export. It can be done, but takes some manipulation to get it into that format. It's a bit too much to get into right now. I can say though that a Jamf employee had posted something not long ago that uses a scripted process to convert API info into a csv format. If I can locate that post again, I'll mention it here for reference.
Thanks a bunch mm2270! I didn't realize I needed to run the output through anything else for a good format (My first time playing with API's if you couldn't tell). My output look a lot better and manageable now!
If you could find that CSV post that'd be great, but if not, at least now I have something I can work with, I'm just more accustomed to parsing CSV. Thanks again.
Glad to help out. The API can be quite cool to work with, but there's also a learning curve for sure. So I understand some of the initial frustration.
I also wanted to mention another point here. It's technically not always necessary to format XML output to get the information you're looking for, even though it's something I do a lot myself.
For starters, be aware that you can actually slim the output of the API call in some cases down to specific data. In the example of pulling a computer record, you can make use of the
subset path. With it, you can get only the General data, the User & Location data and a few other things. This makes the dump of info from the API a little more manageable if you know exactly which section you need to parse. Otherwise, pulling an entire computer record, you'll get sometimes hundreds of lines of installed applications, Extension Attribute values, package receipts and a ton of other stuff that you may not need.
In addition, another useful tool when working with the API is
xpath Here's an example of how I would get the User & Location section of a specific computer by it's Jamf ID, and then extract just the Department string.
curl -H "Accept: application/xml" -su "username:password" https://your.jamf.pro.url:8443/JSSResource/computers/id/10/subset/userlocation | xpath '/computer/location/department/text()' 2>/dev/null
In the above, the
/computer/location/ section is identical to the indents you will see in the XML tree (when using xmllint for example), with
department being the final indent that contains the data I wanted to extract. That should help you know which paths to include when using xpath.
That very useful information, I've only read about xpath and subset in passing; seeing it in use makes a lot more sense. I certainly have a lot to learn when it comes to manipulating the API (or API's in general), but man you really helped break down quite a few walls. Thanks for all the advise!
No problem! Again, glad it helped push you further along.
As for that post from a Jamf employee I mentioned, I located it. You can find it on this Feature Request thread. Look at Daniel MacLaughlin's post, which has a script he created to export saved reports to CSV. Just fair warning - this is a complex script. I'm pretty good with scripting, but some of what he has in there is beyond my knowledge. But, the basis for creating a csv export is in there, if you can figure out how to pull out the relevant pieces and make use of them.