Future proofing REST API calls

[Michail]

In the PTC article, it is stated that the 'appKey as URL parameter' feature will soon be depreciated. How to construct a REST API call with authorisation so that it would work with future versions of ThingWorx?

[sharmon]

Pass the appkey as a header, instead of a URL parameter. Here's an example cURL call for getting a property for a Thing. (The items in curly braces are substitution variables, which works out great, as I don't have to obfuscate anything.):

curl -X GET \
  https://{{host}}{{port}}/Thingworx/Things/BikeSeatThing/Properties/BikeSeatLoad \
  -H 'accept: application/json' \
  -H 'appkey: {{appKey}}' 

I used cURL for my example because it's so common. The technique is applicable across tools that make HTTP calls, though. Just construct your call so appkey is a header, not a URL parameter.

[Michail]

Thank you Stephen Harmon​, I thought that passing an appKey in the header will be depreciated as well.

[sharmon]

Huh. Not that I know of. I do know we're going to start specifically ignoring that URL parameter (unless you configure your ThingWorx instance otherwise, which is not advised). It's not out of the realm of possibility that we'll introduce new authentication methods for REST calls in future releases. I think the header method will work longer than the URL parameter method will, though.

Does anyone else in the community know about plans for the appkey header? In the meantime, I'll ask around.