When initializing the REST Google Drive API in an Android app, I need to 'poke' the server to produce the
UserRecoverableAuthIOException
In order to minimize the network traffic, I'm searching for the most 'lightweight' request that would produce such an exception. Currently, I use the following construct:
com.google.api.services.drive.Drive svc;
svc.files().get("root").setFields("title").execute();
basically pulling the 'root' name.
Is this the lowest amount of traffic that would do the job?
The amount of traffic that is generating is negligible.
It won't count as much at all.
Unless it's for academic purposes you won't achieve anything more from further optimizing for speed. There's a point where it stops being a bottleneck.
So yes that is quite likely the lightest way you can generate the UserRecoverableAuthIOException
Related
When using Forge Data Management API endpoint
projects/:project_id/folders/:folder_id/search we have two problems.
It seems that we sometimes have to wait for several minutes (hours?)
after a model is uploaded until it can be found by the search.
We often get error 429 "Too Many Requests" even that we only call do
very few calls (less than 10 within an hour).
These issues makes the endpoint hard to use in production code. Is there anything we can do to improve the success rate? Is Autodesk going to improve the endpoint?
This question is related to How to find cloud Item id of a Revit model?
We are aware of those issues and working on improving things in those areas. However, I cannot tell when exactly those will become available.
In the meantime, depending on your workflow, there are two things that could be of help:
Use webhooks in order to be notified about new files being added to BIM 360/ACC
Use folder/contents endpoint to find the file you need, which also supports filtering just like the folder/search endpoint. You would have to iterate through subfolders though if you wanted to look for items in them as well. Newly added files should show up here straight away.
I am trying to make public transport time schedule app using google maps directions api.
Whats the best way to get all of the possible departure_time's for a specific route from one place to another from a specific time?
The problem is, the server is always responding with only one route for one specific time. How can I get all of the following departure_times?
The worst way to do this is asking server every minute if there is some new travel link. But hey, its gonna take a lot of time!
So I thought google might be providing some kind of transport schedules but I can't find any info on google developers webs. I saw only the way to give google schedule information with the help of General Transit Feed Specification (GTFS) here or here.
But I can't find the way to get it from them.
I don't believe google maps directions api will return the information you are looking for as a collection.
The problem with transit data is that calculating a future schedule can require a lot of processing (especially if there are multiple routes involved in the rider reaching their destination) because, basically, the system needs to do a trip plan for each scheduled trip at starting point for the time range.
Google hints at this in their API regarding the alternatives parameter
alternatives — If set to true, specifies that the Directions service may provide more than one route alternative in the response. Note that providing route alternatives may increase the response time from the server.
Also, the different future departure times may actually be different routes or combination of routes (e.g. where multiple routes may come together on the same street for a while - for instance, near a college campus or other transit hub)
In order to get the underlying route data that would have the actual stop times you are looking for you would need to download the transit agencies' GTFS data directly and process it yourself (check our GTFS Data Exchange). This is what your competitors are already doing (e.g. Transit App, Moovit, etc.). There are packages that will do some of this processing for you (e.g. One Bus Away). However, even with the use of existing libraries, there is some heavy lifting involved here (from a development point of view).
As a final note, if you want to pursue using google maps directions api you wouldn't need query it for each minute within a time-range in order to get a series of departure times. You should be able to make a series of calls with the departure time set just past the departure time you got back in the previous call. For example, if the first trip time was 1:00pm set departure_time to 1:05pm and request again, then if the second trip time was 1:20pm set the next departure_time to 1:25pm and request again, and so on to build your list of future trips.
Okay. Firstly your question is not in the right spirit as stackoverflow demands. Check at google's developer console , API section and check if they offer any such API to give you all transport schedules in 24hrs or not ? If there is any such API then good, you can hit that but if not then I am afraid you wont be able to get it unless you hit API after some intervals.
Another suggestion is that , you can try yahoo or bing maps and check if they have any such API for your query.
Lets say that the API is well documented and every possible response field is described.
Should web application's server API exclude null fields in a JSON response to lower the amount of traffic? Is this a good idea at all?
I was trying to calculate the amount of traffic reduced for a large app like Twitter, and the numbers are actually quite convincing.
For example: if you exclude a single response field, "someGenericProperty":null, which is 26 bytes, from every single API response, while Twitter is reportedly having 13 billion API requests per day, the amount of traffic reduction will be >300 Gb.
More than 300 Gb less traffic every day is quite a money saver, isn't it? That's probably the most naive and simplistic calculation ever, but still.
In general, no. The more public the API and and the more potential consumers of the API, the more invariant the API should be.
Developers getting started with the API are confused when a field shows up some times, but not other times. This leads to frustration and ultimately wastes the API owner's time in the form of support requests.
There is no way to know exactly how downstream consumers are using an API. Often, they are not using it just as the API developer imagines. Elements that appear or disappear based on the context can break applications that consume the API. The API developer usually has no way to know when a downstream application has been broken, short of complaints from downstream developers.
When data elements appear or disappear, uncertainty is introduced. Was the data element not sent because the API considered it to be irrelevant? Or has the API itself changed? Or is some bug in the consumer's code not parsing the response correctly? If the consumer expects a fields and it isn't there, how does that get debugged?
On the server side, extra code is needed to strip out those fields from the response. What if the logic to strip out data the wrong? It's a chance to inject defects and it means there is more code that must be maintained.
In many applications, network latency is the dominating factor, not bandwidth. For performance reasons, many API developers will favor a few large request/responses over many small request/responses. At my last company, the sales and billing systems would routinely exchange messages of 100 KB, 200 KB or more. Sometimes only a few KB of the data was needed. But overall system performance was better than fetching some data, discovering more was needed then sending additional request for that data.
For most applications some inconsistency is more dangerous than superfluous data is wasteful.
As always, there are a million exceptions. I once interviewed for a job at a torpedo maintenance facility. They had underwater sensors on their firing range to track torpedoes. All sensor data were relayed via acoustic modems to a central underwater data collector. Acoustic underwater modems? Yes. At 300 baud, every byte counts.
There are battery-powered embedded applications where every bytes counts, as well as low-frequency RF communication systems.
Another exception is sparse data. For example, imagine a matrix with 4,000,000 rows and 10,000 columns where 99.99% of the values of the matrix are zero. The matrix should be represented with a sparse data structure that does not include the zeros.
It's definitely dependent from the service and the amount of data it provides; it should be evaluate the ratio about null / not null data and set a threshold over than it worth to exclude that elements.
Thanks for sharing, it's an interesting point as for me.
The question is on a wrong side - JSON is not the best format to compress or reduce traffic, but something like google protobuffers or bson is.
I am carefully re-evaluating nullables in the API scheme right now. We use swagger (Open API) and json scheme does not really have something like nullable type and I think there is a good reason for this.
If you have a JSON response that maps a DB integer field which is suddenly NULL (or can be according to DB scheme), well it is indeed ok for relational DB but not at all healthy for your API.
I suggest to adopt and follow a much more elegant approach, and that would be to make better use of "required" also for the response.
If the field is optional in the response API scheme and it has null value in the DB do not return this field.
We have enabled strict scheme checks also for the API responses, and this gives us a much better control of our data and force us not to rely on states in the API.
For the API client that of course means doing checks like:
if ("key" in response) {
console.log("Optional key value:" + response[key]);
} else {
console.log("Optional key not found");
}
This is using either Bing Maps API or Google Maps API.
Problem: I am trying to create a route for a salesperson that may have 1 or more meetings that day plus visit selections from a pool. Meaning the salesperson has 1 meeting at a client and they want to stop by some leads but around that meeting time.
I doubt either service can handle this problem directly.Is their as way to get a "table of time between destinations" from these services, without running up my requests.
The only way I know how is to submit each variation on the route, store in a table or array, then based on the services "time to get there", calculate the best order. Then resubmit again. My client could easily burn off 20 - 30 requests per try.
Is there any other option? Maybe an free open source one with sh*ty algorithm then submit the final list to one of the above?
You can use the distance matrix service, see the documentation here:
https://developers.google.com/maps/documentation/distancematrix/
In this way, you will be able to compute multiple route between multiple points and certainly reduce the number of requests overall.
If your request is just to get an optimization for a sales man, you can also check the option on Routing service and its optimize option, see: https://developers.google.com/maps/documentation/directions/#Waypoints
On Bing, route optimization (waypoint reordering) is not available yet but you can achieve this with the Route Matrix API.
Recently I found myself in need to perform large batch reverse-geocoding operations.
Large means something about 20k points per request.
I was looking at Nominatim as standalone server. But there is no clue in docs about batch requests (or I just couldn't find it).
Thus the questions is:
1: Could I perform something like this with Nominatim
2: If not - is there other standalone solutions [Not service. May be proprietary]. Main zone of interest is Europe, if it's relevant.
3: What will be approximate time consumption of such request.
Or I am facing building own geocoder above pgsql + postGIS?
thx in advance.
Not a current question, but in the absence of any answers.. There seem to be 2 main solutions. You can either:
use the Google geocoding API, but this will limit you to a check every few seconds, which will make large bulk geocoding very slow, or
download a comprehensive database of place names (such as http://www.geonames.org/), and use a GIS to calculate the nearest points to your data at whatever hierarchical level is most appropriate.