API Call to lookup records, changes responses

[TylerWay]

We have a script to delete existing records from JAMF due to issues with self service not installing after a rebuild. When we first created the script we were getting back a response like "computer":'. Some time later (we can't recall why we change this), the response came back in an xml like format: '<computer><general><id>'. After upgrading the certificate used on the server (SHA-1 to SHA-2) it has reverted back to the original response "computer":'. We are trying to figure out why it is changing (finding the root cause). Any help is appreciated.
The command we used was:

curl -ksu $LOGIN:$PASS "$JSSURL/JSSResource/computers/serialnumber/$SERIAL"

[mm2270]

@TylerWay The "computer":' response you were getting is JSON, which the JSS will now default to, under most circumstances. The <computer> formatted responses are XML. Generally now, you have to specify the header you would like from the API, at least to ensure you get XML instead of JSON. If you want JSON, then normally you don't need to do anything as it will often default to that.

As to why the cert change prompted it to go from JSON to XML and back to JSON, I'm not sure, but I'd imagine it has something to do with a security preference within the API on the type of response to send back.

In case you're interested, here's how to add a header to your command above to get XML. I'm not sure of the exact syntax to force JSON, but if you search around, you may find that info.

curl -H "Accept: text/xml" -ksu $LOGIN:$PASS "$JSSURL/JSSResource/computers/serialnumber/$SERIAL"

As to which one to use, it's a matter of personal preference and what you feel comfortable with in using in your scripts. I tend to use xml myself, but some folks swear by JSON.

[TylerWay]

That is what we are thinking as well, just was wondering if anyone else has run into something like this, or knew more about this.

[mm2270]

Yeah, I can't explain why it changed for you, but I can say that, going back a ways to earlier 9.x versions of the JSS we used to always get XML back from an API call. Then after one of our upgrades we started getting JSON by default. Now I include the above header with any API call to get XML and don't have a problem with scripts breaking anymore.
Again, I can't really explain what caused the exact shifts you saw, but I would just pick a format for your scripts and make sure any API calls in any scripts are using that header to ensure the output back you want, and you should be OK.

[MacTool]

Ours changed to defaulting to JSON after an API update on the server. Caught us off guard as I have some scripts I use for a live sync of data from old computers to new, replacement computers before delivery that are dependent on the API responses being XML. Worked one week and then the next everything was failing. Solved in the same manner by explicitly making the JSS return XML.

Even the JSS API page doesn't always return both XML and JSON in the responses for certain types. But lesson learned.

Glad we caught it before starting my scripts to clean up policies and groups created by AutoPKGR.

[talkingmoose]

From what I understand, newer versions of Java cause the Jamf server to return JSON instead of XML. You generally won't see this happen until you restart Tomcat, which is why it appears updating the JSS causes the issue.

Why you may have seen a flip-flop back and forth I don't know. The solution is to include the -H "Accept: text/xml" argument to the curl command as @mm2270 recommends. This will give you reliable results.