API curl xpath GET suddenly stopped working....

shurkin18
Contributor II

It is very strange how suddenly the xpath GET stopped printing the data correct, for this line:

id=`/usr/bin/curl -k -u $user:$pass "$jssurl/JSSResource/computers/udid/$uuid" -X GET | xpath //computer/general/id | cut -f2 -d ">" | cut -f1 -d "<"`

Getting this output with ALL the data from JSS on that specific computer:

% Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 37386 100 37386 0 0 43174 0 --:--:-- --:--:-- --:--:-- 43170 not well-formed (invalid token) at line 1, column 0, byte 0: {"computer":{"general":{"id":1992,"name": ..... .... [ALL THE DATA] .... ^ at /System/Library/Perl/Extras/5.18/darwin-thread-multi-2level/XML/Parser.pm line 187.

It displayed computer id before and now all data raw...

I wonder why it stopped working like that, any ideas?

1 ACCEPTED SOLUTION

SamF
Contributor

It looks like the response is in JSON, and xpath is for parsing XML. You'll want to add an Accept header to specify that you'd like to receive XML. More information on supported schemas and the Accept header are available on the Developer Portal

View solution in original post

4 REPLIES 4

SamF
Contributor

It looks like the response is in JSON, and xpath is for parsing XML. You'll want to add an Accept header to specify that you'd like to receive XML. More information on supported schemas and the Accept header are available on the Developer Portal

View solution in original post

shurkin18
Contributor II

That's what was it, thanks Sam! I wonder why it worked before πŸ™‚

SamF
Contributor

Jamf Pro doesn't have a default return type which means that the data type returned is determined by the underlying infrastructure (Tomcat and Java). The upgrade to one or both likely triggered the change in behavior, which is why it's recommended to add the Accept header to all scripts or tools that use the API.

shurkin18
Contributor II

Makes sense, thanks!