query realtime data by passing multiple XID

[djmolloyjr22]

Hello,

Using the new beta 1.6, trying to use REST/SWAGGER to query the latest real-time read data for multiple XID. For example, the query would be something like: ?XID0=DP_622107&XID1=DP_621502&XID2=DP_622361 and the return would be a set of the 3 values.

Thanks,

Dan

[terrypacker]

Dan,

We don't currently support IN style queries in RQL yet. We are planning to add this but in the meantime you could use a LIKE query. Unfortunately I have found a bug in the LIKE query for the realtime endpoint so you will need to upgrade the 2.6 core when we push out the fix.

When the fix is ready you can use a query like this:

/rest/v1/realtime.json?like(xid,DP_62.*)

In the LIKE query you can use the dot star notation for a wildcard. For example

test.* --> Matches test_1 or testAgain

.* --> Matches everything

.*test --> Matches 1_test or againTest

We use Regular expressions for string matches in RQL so any of the Java regex patterns and classes are valid so long as you escape them properly in the URL.

But this will likely return more than your desired results if other XIDs match that pattern.

I would suggest either placing all the points under some path in the point hierarchy and then using this query:

/rest/v1/realtime.json?like(path,my_path_to_points)

Or renaming the XIDs to something more meaningful for this purpose:

DP_groupA_member0
DP_groupB_member1

Or using the point name in the same manner.

Thanks,
Terry

[djmolloyjr22]

@terrypacker

We had a little trouble with the path until we realized we needed to escape the slashes. For example: /rest/v1/realtime.json?like(path,/datacenter/5/room/4) would need to be sent as: /rest/v1/realtime.json?like(path,%2fdatacenter%2f5%2froom%2f4%2f)

[terrypacker]

One quick note:

In the latest nightly build of 2.6.0 we are removing the ability to add the .json to the end of the URLS for the REST api. This was done because we found we could not easily interpret dots in other areas of the URL. So for example:

/rest/v1/users/admin.json

must now be:

/ret/v1/users/admin

This better allows us to do things like:
/rest/v1/users/firstname.lastname

The other feature this effects is the ability to define the content type using a file extension on the URL. So for example previously one could request a csv file:

/rest/v1/data-points/data-source/DS_XID.csv

Or a JSON file:

/rest/v1/data-points/data-source/DS_XID.json

One must now use:
/rest/v1/data-points/data-source/DS_XID?format=csv
OR
/rest/v1/data-points/data-source/DS_XID?format=son
OR
Set the accept header in the request to the desired file type (CSV or JSON support only for now)