3 Replies Latest reply on Jan 17, 2018 4:21 PM by mnudel RSS
    mnudel Apprentice

    Future proofing REST API calls

    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?

      • Re: Future proofing REST API calls
        sharmon Creator

        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.

          • Re: Future proofing REST API calls
            mnudel Apprentice

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

              • Re: Future proofing REST API calls
                sharmon Creator

                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.