Uber API v1.2 Documentation GET /estimates/price contains an ambiguity in the definition of surge_multiplier support:
it is declared as one of the parameters of the response
but
not presented in the example of response
Additionally I checked answer and comments on the similar Question and found mutually exclusive info given there:
"surge multiplier should not be returned in v1.2." vs the answer with an example of the response containing surge_multiplier
so what is valid and expected behaviour for this endpoint?
Related to the "GET /estimates/price" endpoint following is stated in Uber documentation:
When surge is active for a particular product, its surge_multiplier will be greater than 1, but the price estimate already factors in this multiplier.
Documentation also state that there is a option to get "surge_multiplier":
surge_multiplier float Expected surge multiplier. Surge is active if surge_multiplier is greater than 1. Price estimate already factors in the surge multiplier.
So if there is no "surge_multiplier" returned - it is always assumed to be equal to 1. If "surge_multiplier" is greater then 1 than this parameter should be displayed. But besides if this parameter is displayed or not - if there is a surge in place for the product - price estimate already factors in this multiplier.
Related
The bounty expires in 2 days. Answers to this question are eligible for a +50 reputation bounty.
Golak Sarangi wants to draw more attention to this question:
I am also facing a similar issue where the dimensions in the results change based on the metric used. For a certain date range I get 24 cities when I query for totalUsers but 402 cities when I query for sessions.
I'm migrating an app from the Reporting API V4 to the new Data API V1 to support GA4 properties.
While the sessions metric aggregation is usually a few sessions off when adding multiple dimensions or requesting multiple days, adding an event-specific conversions count metric to the report request produces a considerable increase in the number of sessions on the result rows - by a factor of ~4x from my empiric observations.
Request JSON with only the sessions metric and the date dimension:
{"dimensions":[{"name":"date"}],"metrics":[{"name":"sessions"}],"dateRanges":[{"startDate":"2022-12-01","endDate":"2022-12-01"}],"metricAggregations":["TOTAL"]}
Results: 612 sessions on the response row | 612 sessions in Metric Aggregations
Request JSON with the additional conversions:purchase metric:
{"dimensions":[{"name":"date"}],"metrics":[{"name":"sessions"},{"name":"conversions:purchase"}],"dateRanges":[{"startDate":"2022-12-01","endDate":"2022-12-01"}],"metricAggregations":["TOTAL"]}
Results: 2527 sessions on the response row | 612 sessions in Metric Aggregations
Note: this behavior is consistent throughout multiple properties, even for those with no conversions:purchase events.
Is this an API bug, or am I missing something? Is there something I can do to get accurate results?
It may be opinionated and not belong here, but I don't seem to find any info about this.
I have a 'sales' resource so I can GET, POST, PUT, DELETE sales of my store.
I want to do a dashboard with information about those sales: e.g the average sales per day of the last month.
Since REST is resource-oriented, that means I have to manually retrieve all sales of the last month and calculate the average per day on client using GET /sales?sale_date>=...? That doesn't seem optimal, since I could have thousands of sales in that period of time.
Also, I don't think REST can allow a URL like GET /sales/average-per-day-last-month. What is the alternative of doing this?
I don't think REST can allow a URL like GET /sales/average-per-day-last-month
Change your thinking - that's a perfectly satisfactory URL for a perfectly satisfactory resource.
Any information that can be named can be a resource -- Fielding, 2000
"Any information that can be named" of course includes "any sales report that you can imagine".
GET /sales/average-per-day-last-month HTTP/x.y
That's perfect. Depending on your needs, you might also want to have other resources that are the "average-per-day" report for specific months.
GET /sales/2021-02/average-per-day HTTP/x.y
REST doesn't constrain your resource model at all; and it doesn't constrain your resource identifier design beyond expecting conformance to the production rules described by RFC 3986.
Am I able to set the maximum number of possible UberPOOL riders in a vehicle to something higher than 4 or 6? I'm working on a request-based shuttle program and would like to see if I could make use of the UberPOOL API for this project. Ideally I would like to bump up the number of riders in a vehicle to something much higher, probably around 10 - 15 per shuttle.
According to the api documentation for v1.2. The max seat allowed for a uberpool is is 2. So you will not be able to request more than that. The best alternative is use uberx and XL for your request api call. However the max for UberXL is 6 occupants and the for uberx is 4 occupants.
I'm designing a restful API. In this API it's possible to POST, DELETE and GET cases using the API. If there is a case that you find particularly important its possible to put a "vote" on it so that a case becomes more prioritized.
However I am wondering what type of method this should be?
Which one should it be:
GET /cases/{case_id}/vote
POST /cases/{case_id}/vote
PUT /cases/{case_id}/vote
Calling the vote method will only increase the number of votes by 1.
I'm currently leaning towards PUT myself seeing as how it's an update of an existing number (although POST could also be used for this) but I am wondering what the convention is.
First I would name the resource
/cases/{case_id}/votes
which makes it clear that this is the resource for the votes of the case.
Then use
POST /cases/{case_id}/votes
on this resource. On the server the count of votes would be increased by one.
Don't use PUT because this would mean that the client is in control of the total number of votes which is not correct. The client only triggers the increas by one, it is not setting the total number of votes.
What is the max value for the parameter limit for /me/friends/ and /me/likes?
I can't find any documentation regarding the parameters.
A general rule of thumb is not to use a limit higher than 100, and use paging to get the next batch. For example, page related maximum limits are 100: https://developers.facebook.com/docs/apps/changelog#v2_4
API calls with a higher limit will take longer, and since you can only get friends who authorized your App too, it is a good idea to keep the limit for /me/friends small anyway.