Following this tutorial - weather using rest api calls - I’m trying to extend the example to gather the 1 hour accumulated rain data.
The Openweather api docs state:
If you do not see some of the parameters in your API response it means that these weather phenomena are just not happened for the time of measurement for the city or location chosen. Only really measured or calculated data is displayed in API response.
No accumulated rain volume means there is no rain section in the response. How do I deal with this in the rule engine? Essentially a conditional rule (if rain.1h is present, use rain.1h, else set rain.1h = 0)
Thanks
Rule Chain script is based on JavaScript. Response from thirdparty service will be in msg.
To check if rain.1h is in response:
if (msg.rain && msg.rain.1h) {
...
}
Related
We are using the Routing API V8. When I call the API. I am getting a return result of
2021-03-03T18:09:52+10:00 But from the maps website. I am getting a result of https://wego.here.com/directions/mix/6-Kyabra-St,-Newstead-QLD-4006,-Australia:-27.45264,153.04265/35-Hercules-St,-Hamilton-QLD-4007,-Australia:-27.43945,153.06973?map=-27.44536,153.05502,15,normal It says a 12 minute travel time.
Here is my API Call: https://router.hereapi.com/v8/routes?transportMode=car&origin=-27.452630,153.042350&destination=-27.439750,153.069630&departureTime=2021-03-03T08:00:00Z&apiKey=
Here is the full response from the API:
{"routes":[{"id":"3ff8ffc9-1f66-4b47-9ec0-a59cf2268348","sections":[{"id":"e4154bf2-2052-4846-b46c-5cfe4b4cfc01","type":"vehicle","departure":{"time":"2021-03-03T18:00:00+10:00","place":{"type":"place","location":{"lat":-27.4526753,"lng":153.0426484},"originalLocation":{"lat":-27.45263,"lng":153.0423499}}},"arrival":{"time":"2021-03-03T18:09:52+10:00","place":{"type":"place","location":{"lat":-27.4396845,"lng":153.0693942},"originalLocation":{"lat":-27.4397501,"lng":153.06963}}},"transport":{"mode":"car"}}]}]}
Based on HERE routing API v8 documentation, when I removed Z from end of departureTime parameter in order to assume time is local to the origin, the time is shown correctly:
....
departure": {
"time": "2021-03-03T08:00:00+10:00",
....
arrival": {
"time": "2021-03-03T08:10:20+10:00",
...
During an update of streaming jobs (via REST Api, we use the generic one that allows to update any kind of resource: https://learn.microsoft.com/en-us/rest/api/resources/resources/updatebyid), I get 422 without any additional information. Could anyone help with identifying the problem ?
Well, although there is very little useful information in your question, I eventually reproduce your issue on my side.
The reason has been described clearly by the error message :
PATCH of Inputs, Transformation, Functions, Outputs or Devices is not allowed using the Streaming Job level API. Please use the API for the corresponding resources.
This means you could not include the Inputs, Transformation, Functions, Outputs, Devices in your request body, because they are different resources form the streamingjobs.
Solution:
To fix the issue, just use the API for the corresponding resources as mentioed in the error message.
1.Update Input : PATCH https://managment.azure.com/subscriptions/{subscription-id}/resourceGroups/{resource-group-name}/providers/Microsoft.StreamAnalytics/streamingjobs/{job-name}/inputs/{input-name}?api-version={api-version}
2.Update Function : PATCH https://<endpoint>/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.StreamAnalytics/streamingjobs/{jobName}/function/{functionName}?api-version={api-version}
3.Update Output : PATCH https://managment.azure.com/subscriptions/{subscription-id}/resourceGroups/{resource-group-name}/providers/Microsoft.StreamAnalytics/streamingjobs/{job-name}/outputs/output?api-version={api-version}
4.Update Transformation : PATCH https://management.azure.com/subscriptions/{subscription-id}/resourceGroups/{resource-group-name}/providers/Microsoft.StreamAnalytics/streamingjobs/{job-name}/transformations/{transformation-name}?api-version={api-version}
For more details, you could refer to Stream Analytics REST API.
Sample:
I test to Update Input.
PATCH https://managment.azure.com/subscriptions/xxxxxx/resourceGroups/joywebapp/providers/Microsoft.StreamAnalytics/streamingjobs/joyteststream/inputs/joyinput?api-version=2018-11-01
Request body:
{
"properties":{
"type":"Stream",
"serialization":{
"type":"JSON",
"properties":{
"encoding":"UTF8"
}
}
}
}
Result:
We are currently trying to come up with a set of REST API that would fit our resource models.
A simplified example of the resource is:
CompanyInfo: {
totalNumberOfEmployees: Number,
employees: [...employees],
}
Employee: {
name: String,
}
In this case, "CompanyInfo" is like a virtual resource that does not exist in DB. It is a short cut for getting all the data related to the Company resource. The idea was to reduce the amount of logic on FE and create more convenient endpoint instead.
Our current endpoint design is:
GET /api/companyInfos/{companyId}/employees
GET,POST,PUT,DELETE /api/companyInfos/{companyId}/employees/{employeeId}
The reason for the extra {companyId} is because these endpoint does not return "Employees", it instead return a "CompanyInfo" that contains "Employees" embedded in the payload.
This is to avoid the aggregated property "totalNumberOfEmployees" not being updated in case sync when we call POST to create a new "Employee"
So my questions are:
Is this the correct approach to the problem of "too many requests" or "too much logic in FE"?
Is it acceptable for the endpoint to return a completely different resource than what its url describe?
Thanks a lot :)
For your Fist question
Is this the correct approach to the problem of "too many requests" or "too much logic in FE"?
yes Sometimes this is how it is suppose to be done. when data sent is small in each request. to many request does not affect the performance so This is how it is suppose to be done .
And Generally it is recommended to write one monolithic Ajax call in front end which will be capable of making any kind of call , By taking callback as parameter, and method , arguments as parameters .
So it will not be to much of logic if you follow this approach . All you have to write is callback for each of Ajax call . How ever sometimes situation may not allow for this Example:if you are using content-type like 'multipart/mixed'
there you have to write another ajax call code
However nowdays most front end has too much of logic based on how interactive website is . So your primary concern should be about look of web site .
For you second question
Is it acceptable for the endpoint to return a completely different resource than what its url describe?
yes . It is acceptable . but it is recommended that client mention all the MIME types which it expects in Accept header and Only those MIME types should be returned by Api.
I have a RESTful API that I would like to run some tests against at random moments of the day in order to check the average response time. I wasn't able to do this using Postman's Collection Runner. Is there another tool which allows me to do this, or maybe I'll have to write my own?
You can use services like Pingdom to retrieve calls from your API, or you can use softwares (commercial or opensource, is Zabbix still around?) to monitor your API, or (if you don't need many perks) you can write yourself a script that runs in a cronjob and saves the response time of your API in a txt file (or wherever you want) for further inspection.
Here's a little example, in php, but you can easily adapt it to your fav. language.
// I don't know how much will it take to run the API request
set_time_limit(0)
$start = microtime(true);
$result = executeApiCall()
$executionTime = microtime(true) - $start;
storeExecutionTime($executionTime)
function storeExecutionTime($time) {
// store the data somewhere
}
could anybody please tell me how to obtain the precipitation (rainfall) from Yahoo Weather via Temboo?
I work at Temboo.
Yahoo's response body doesn't include data for precipitation. However, you can get it from the Weather Underground API. Here's a snippet from a response:
"UV":"1","precip_1hr_string":"0.00 in ( 0 mm)",
"precip_1hr_in":"0.00",
"precip_1hr_metric":" 0",
"precip_today_string":"0.00 in (0 mm)",
"precip_today_in":"0.00",
"precip_today_metric":"0",
If you want to use The Weather Underground API via Temboo, you should take a look at our HTTP Choreos - they let you connect to any API that we don't currently provide first-class support for:
https://temboo.com/library/Library/Utilities/HTTP/