the way you get closest to what you need is the following:
change the following two headers of your REST request call:
Accept : text/csv
Content-Type : text/csv
To get a correctly formatted result with a system >=6.5 you'll have to change a setting in the Platform Subsystem: Switch off Filter Content Type'. This has some security impact, see Updating the Request Method and Content Type Filtering for CSRF Protection in the 6.6 HelpCenter.
The result will return your String in the second line (the first will be the header column. i.e. the name of the property, by default this is result.
I just tried these settings and invoked a getStringValue service on a TestThing Thing that returns a String. The invocation URL is:
and the result will then be:
Here is s screenshot of my Postman request:
I believe you are doing proper POST calls so you won't have to turn on the switch.
For the service return values, you can first of all define in the Service what the result parameter basetype is, so could even just be a number or string or boolean.
then with the Accept header you can get text, text/xml, text/csv, application/json returned
Thanks, Moritz and Pai. Close is good - thanks for the suggestion on using text/csv. However, this solution will still require a small change in the edge device firmware.
I guess the real question is, when connecting with edge devices with a predefined API, Is it possible to customize the corresponding Thing services in a way that would allow me to, for example, control the exact encoding of the result in the HTTP response or use certain values from the HTTP URL and header?
Or, said another way, how does one produce a Thingworx extension to talk to a proprietary or non-standard device?
In one specific case, the device says it is expecting application/json of a dateTime offset value, but it is not expecting the InfoTable metadata that my service sends with the response. But there are other cases where the return value is different and I am looking at this as a general problem. These service also need to read values from the HTTP POST URL and/or header. Whatever the existing API is I need to develop services that match..
Hi Andy, if you want to use the Calls your equipment is making right now, there will be some major changes needed on the platform, as I indicated, Thingworx REST API can't consume the additional pieces you have in the URL.
So all the information will have to go to the Parameter declaration.
However when it comes to return values, again you can create services to create any BaseType information within Thingworx that you'll be calling and those can come back in text / xml / json or csv
Without a doubt some work will be involved on both ends.