I'm trying to retrieve aggregate daily heart rate summary data using the Google Fit REST API, but I'm struggling because either I'm missing something or the documentation seems to be very incomplete. I've successfully managed to retrieve aggregate daily step count by following one of the few available examples:
Request URL
https://www.googleapis.com/fitness/v1/users/me/dataset:aggregate
Request body
{
"aggregateBy": [{
"dataTypeName": "com.google.step_count.delta",
"dataSourceId": "derived:com.google.step_count.delta:com.google.android.gms:estimated_steps"
}],
"bucketByTime": { "durationMillis": 86400000 },
"startTimeMillis": 1438705622000,
"endTimeMillis": 1439310422000
}
I can't find any example for reading heart rate, so I'm trying to modify this for heart rate. I found this list of data types where it has this data type: com.google.heart_rate.summary but there isn't any information on what the dataSourceId should be. I tried just omitting it but I get this error:
no default datasource found for: com.google.heart_rate.summary
Does anybody know what I need to use for dataSourceId, or have a link to any decent documentation on data sources?
For resting heart rate, I use this:
"derived:com.google.heart_rate.bpm:com.google.android.gms:resting_heart_rate<-merge_heart_rate_bpm"
For heart rate or BPM, I use this:
"derived:com.google.heart_rate.bpm:com.google.android.gms:merge_heart_rate_bpm"
For completeness, I have included the datasources that I am using below for various readings:
DATA_SOURCE = {
"steps": "derived:com.google.step_count.delta:com.google.android.gms:merge_step_deltas",
"dist": "derived:com.google.distance.delta:com.google.android.gms:from_steps<-merge_step_deltas",
"bpm": "derived:com.google.heart_rate.bpm:com.google.android.gms:merge_heart_rate_bpm",
"rhr": "derived:com.google.heart_rate.bpm:com.google.android.gms:resting_heart_rate<-merge_heart_rate_bpm",
"sleep" : "derived:com.google.sleep.segment:com.google.android.gms:sleep_from_activity<-raw:com.google.activity.segment:com.heytap.wearable.health:stream_sleep",
"cal" : "derived:com.google.calories.expended:com.google.android.gms:from_activities",
"move": "derived:com.google.active_minutes:com.google.android.gms:from_steps<-estimated_steps",
"points" : "derived:com.google.heart_minutes:com.google.android.gms:merge_heart_minutes",
"weight" : "derived:com.google.weight:com.google.android.gms:merge_weight"
}
Depending on the datasource, sometimes it will provide an array of points. You can then choose to take sum, mean, median, etc of all points in the array accordingly.
You can list the data sources available for a given data type, for example :
Method
GET
Request URL
https://www.googleapis.com/fitness/v1/users/me/dataSources?dataTypeName=com.google.heart_rate.summary
Depending on what you're trying to achieve, you'll probably find a source either for com.google.heart_rate.summary or com.google.heart_rate.bpm to meet your needs, including merged sources.
Related
I am trying to perform aggregate queries using SumoLogic APIs as mentioned here.
Something like:
_view = <some_view> | where sourceCategory matches \"something\" | sum(field) by sourceCategory
This works just fine in the Sumo GUI. I get a field in result called "_sum" which gives me the desired result.
However the same doesn't work when I do it using the SUMO APIs. If I create a job with this body:
{
"query": "_view = <some_view> | where sourceCategory matches "something" | sum(field) by sourceCategory",
"from": "start_timestamp",
"to": "end_timestamp",
"timeZone": "some_timezone"
}
I call the "v1/search/jobs" POST method with the above body and I do GET "v1/search/jobs/{job_id}" till the state is "DONE GATHERING RESULTS". Then I do "v1/search/jobs/{job_id}/messages". I was expecting to see aggregated values in the result, but instead I see something similar to:
{
"fields":[
{
"name":"_messageid",
"fieldType":"long",
"keyField":false
}, ...
],
"messages":[
{
"map":{
"_receipttime":"1359407350899",
"_size":"549",
"_sourcecategory":"service",
"_sourceid":"1640",
"the_field_i_mentioned":"not-aggregated-value"
"_messagecount":"2044"
}
}, ...
]
]
Thanks for going through my question. Any advices / work-arounds are appreciated. I don't really want to iterate manually through all items and calculate the sum. I'd prefer to do it on SumoLogic side itself. Thanks Again!
Explanation
Similar as in the User Interface, in the API for log searches you get both raw results (also referred to as messages) and the aggregate results (also referred to as records).
(Obviously, the latter are only returned if there's any aggregation in the query. In your case there is.)
Actual suggestion
Then I do "v1/search/jobs/{job_id}/messages"
Try /records instead.
See the docs for "Paging through the records found by a Search Job"
Disclaimer: I am currently employed by Sumo Logic.
After integrating the Google DLP API, the ListInfoTypes() currently returns the name, description, supported types of the infotypes present in the infotypes reference. Is it possible to also obtain the region for the infotypes like "Australia" or "Argentina" as a seperate field?
Currently this is my output:
"name": "AUSTRALIA_MEDICARE_NUMBER",
"displayName": "Australia medicare number",
"supportedBy": [
"INSPECT"
],
"description": "A 9-digit Australian Medicare account
I need the Region as well for example Region: "Australia" for every other infotypes.
I also got around to see locations.infoTypes.list() but I'm not sure which location I should enter in the filter to get any value.
Looking at the REST API there doesn't appear to be identifying data that can be formally used to determine the region. If we look at the InfoTypeDescription JSON structure found here:
https://cloud.google.com/dlp/docs/reference/rest/v2/ListInfoTypesResponse#InfoTypeDescription
we see that "name" is described as an "internal name of the InfoType". I wondered if we could depend on a structure of the string ... perhaps (.)*_.* as a regular expression grouping. While this might work, it shouldn't be relied upon without investigation of more samples and the docs don't describe the structure.
If you really need a solution, my recommendation would be to dump ALL the InfoTypes and then manually group the "name" fields into the regions of interest to you. You could then store this as CSV or JSON and have a reference piece of data that you could use in your app and regenerate as needed.
It's a great feature request I'll forward to the team. In the short term you can hack the name as ones that are regional will say they are in their name.
I am working on Schema.org Resort schema for a ton of resorts on a travel website and am trying to find the most efficient ways of filling out the schema with regards to amenities.
The current code looks something like this:
"amenityFeature": [
{
"#type":"http://schema.org/LocationFeatureSpecification",
"name":"Spa",
"value":"true"
},
{
"#type":"http://schema.org/LocationFeatureSpecification",
"name":"Internet Access",
"value":"true"
},
{
"#type":"http://schema.org/LocationFeatureSpecification",
"name":"Tennis Courts",
"value":"true"
}
]
My question is, can I write it like this instead to shorten lines of code:
{
"#type":"http://schema.org/LocationFeatureSpecification",
"name":[
"Spa", "Internet Access", "Tennis Courts"
],
"value":"true"
}
When I test it in Google’s Structured Data Testing Tool, it doesn’t give any errors. Here is what it looks like in the SDTT when I write it the short way:
And here is what it looks like if I do it the first/long way:
If I do it the short way, I want to make sure all those items are getting listed as amenities and not just different names for the same amenity. Otherwise, I'll go the long route.
No, each LocationFeatureSpecification represents one feature:
Specifies a location feature by providing a structured value representing a feature of an accommodation as a property-value pair of varying degrees of formality.
Your second snippet would represent one feature with multiple names.
im having the following error with my Amadeus API integration, with the following hit as example:
https://test.api.amadeus.com/v2/shopping/hotel-offers?cityCode=MAD&roomQuantity=1&adults=2&radius=5&radiusUnit=KM&paymentPolicy=NONE&includeClosed=false&bestRateOnly=true&view=FULL&sort=NONE
In this example, im trying to find hotels in the MAD IATA code, which can be either Barajas Airport, or Madrid itself. This throws response 200 (meaning OK), but the data is empty like no hotels.
Another example of this happening is in AMS (Amsterdam or the airport itself)
I thought it could be some crash between cities and airport with the same IATA code, but BCN (Barcelona and El Pratt airport) works fine.
Have anyone else faced this issue?
I just tried your example in test and it works for me:
https://test.api.amadeus.com/v2/shopping/hotel-offers?cityCode=MAD&roomQuantity=1&adults=2&radius=5&radiusUnit=KM&paymentPolicy=NONE&includeClosed=false&bestRateOnly=true&view=FULL&sort=NONE
"type": "hotel",
"hotelId": "BWMAD200",
"chainCode": "BW",
"dupeId": "700009576",
"name": "BEST WESTERN HOTEL LOS CONDES",
...
2 things to keep in mind:
You use the test environment, in this environment the data set is limited (enough to prototype) if you want to get access to the full set of data you will have to move to production.
You are doing a hotel search, it could that it didn't find available rooms at the moment you did the request for the provided parameters (link to the previous point where the data set is limited). You can play with the radius and the roomQuantity to find more hotels.
I'm seeing this too.
I cannot find a combination of fields that returns any data for any of the MAD or NYC city codes.
LON is the only city code that I can get search results from, but only if I specify dates earlier than April.
Searching for MAD without dates
Query:
https://test.api.amadeus.com/v2/shopping/hotel-offers?cityCode=MAD&roomQuantity=1&adults=2&radius=5&radiusUnit=KM&paymentPolicy=NONE&includeClosed=false&bestRateOnly=true&view=FULL&sort=NONE
Results:
{
"data": [],
"meta": {
"links": {
"next": "https://test.api.amadeus.com/v2/shopping/hotel-offers?adults=2&bestRateOnly=true&cityCode=MAD&includeClosed=false&paymentPolicy=NONE&radius=5&radiusUnit=KM&roomQuantity=1&sort=NONE&view=FULL&page[offset]=H0227D1ADVO9_100"
}
}
}
Searching for LON in April
Query:
https://test.api.amadeus.com/v2/shopping/hotel-offers?cityCode=LON&checkInDate=2020-04-04&checkOutDate=2020-04-09&roomQuantity=1&adults=2&radius=5&radiusUnit=KM&paymentPolicy=NONE&includeClosed=false&bestRateOnly=true&view=FULL&sort=NONE
Results:
{
"data": [],
"meta": {
"links": {
"next": "https://test.api.amadeus.com/v2/shopping/hotel-offers?adults=2&bestRateOnly=true&checkInDate=2020-04-04&checkOutDate=2020-04-09&cityCode=LON&includeClosed=false&paymentPolicy=NONE&radius=5&radiusUnit=KM&roomQuantity=1&sort=NONE&view=FULL&page[offset]=IHNILC3OTZSM_100"
}
}
}
Searching for LON in March
Query:
https://test.api.amadeus.com/v2/shopping/hotel-offers?cityCode=LON&checkInDate=2020-03-04&checkOutDate=2020-03-09&roomQuantity=1&adults=2&radius=5&radiusUnit=KM&paymentPolicy=NONE&includeClosed=false&bestRateOnly=true&view=FULL&sort=NONE
Results:
Success
I agree that it's not very clear which searches we should expect to be successful. Is there a date limitation that I'm not aware of? Which cities are supported?
The only information around what limitations we should expect from hotel searches in the test environment that I've seen seems to code from your test dataset repository:
The content of Hotel Search comes directly from the hotel providers, so the content might change dynamically. For your test, use big cities like LON (London) or NYC (New-York).
I doubt what's the best way to address an ordered list in a RESTful API. Imagine the following example: Let's create a chart list of LPs, where you want to add new LPs, delete those which aren't in the TOP10 yet, and change their positions. How would you implement those methods in a RESTful JSON-API?
I thought of the following way:
GET / to return the ordered chart list like [{ "name": "1st-place LP", "link": "/uid123" }, { "name": "2nd-place LP", "link": "/uid987" }, ...]
GET /{uid} to return a LP by its unique ID, returning sth. like {"name": "1st-place LP", "ranking": 1 }
GET /ranking/{position} to access e.g. the current first-ranked LP, returning a 303 See Other with a Location-header like Location: /uid123
POST / with request body { "name": "my first LP title" } to create a new LP without specifying its current chart position
Now it's the question how we could change the current chart positions? One could simply PUT /{uid} to update the ranking attribute, but I think a PUT /ranking/{position} would be more natural. On the other hand it doesn't make sense to PUT against an URI which will return a 303 See Other when using GET.
What do you think would be the best way to address such a chart list? I don't like the solution of changing simply the ranking attribute in the LP-datasets as this could end in senseless states like two LPs with the same ranking and so on.
I see two questions. 1. What is the most RESTful (beautiful) way to design the API? 2. How do I make sure that two LPs does not get the same ranking?
1:
Your LPs could have several properties that are relative to eachother, e.g. different ranking on different charts. I would say that you want the ranking moved OUT of your LP resource. Keep the ranking on a certain list as a separate resource. Example:
GET /LPuid only returns properties about the LP, not relative properties, like rankings
GET /billboard/3 returns the URI to LP that has rankning 3 on the billboard list.
PUT /billboard takes a document of 100 LP URI's.
PUT /billboard/3 INSERTS an LP URI at that ranking and moves the other ones down.
2: That has nothing to do with rest and you would have that issue no matter how you design your API. Transactions is one solution.
You have two collection resources within your music service. As such, I would design a URI structure like this:
/ => returns links to collections (ergo itself a collection resource)
/releases => returns a list of LPs
/chart => returns the top 10 LPs, or redirects to the current chart URI
You would POST to /releases to add a new LP, and PUT or PATCH to /chart to define a new chart or alter the current chart. You will need to define what representation formats are transfered in each case.
This gives you the flexability to define thinks like /chart/2012-12-25 to show the chart as it stood on christmas day 2012.
I do not suggest using PUT /chart/{position} to insert an LP at a specific position and shuffle everything else down. Intermediarys would not know that a PUT to that URI causes other resources to change their URIs. This is bad for caching.
Also, as a user, I would hope you avoid the word "billboard" as the other answer suggests. A billboard conjures in the mind pictures of an advertising hoarding, and not anything to do with ranking charts!