3 ms·

I get why this feels like a good idea, and I’ve wanted similar myself, but having built APIs, ensuring that users use them correctly is hard. Designing APIs tha

I get why this feels like a good idea, and I’ve wanted similar myself, but having built APIs, ensuring that users use them correctly is hard. Designing APIs that are hard to use wrongly is tricky, but a much better approach than documentation. There are lots of other reasons and it’s easy to jump to Google wanting to protect their data, but creating correctly usable APIs is a generally applicable reason that is perhaps more charitable.

londons_explore 3y ago
Whats wrong with "all maps stuff is in this huge bigquery table. Here are a bunch of example queries to get you going." SELECT business_name, business_phone FROM pois WHERE business_type = 'bank' and place_review_count > 10 ORDER BY distance(Location('New York'), location) ASC LIMIT 10; Doesn't seem particularly hard for users to use 'right' - most people using an API will have some technical background and be able to use that.
- danpalmer 3y ago
  Example, purely hypothetical for this scenario, but based on a real experience I had recently... What if there was a data source that went into this from a third party? What if that third party had requirements about the timeline of removing data? This could be because it contained user-generated content and something was found to be offensive or even illegal, or it could be because it contained something proprietary that needed to be correctly licenced, all sorts of possibilities. If you provide a data dump, you then need any integrators to add a data refresh process. That's an additional step that many won't do. Now you can't honour contracts or potentially legal requirements. Sure you can document this, sure you can put it in contracts, but that may not be enough.
- amichal 3y ago
  "map stuff" is much harder to understand than your query implies. As an example Have you tried understanding all the possible things that you can get in 'address_components' depending on the input params, the region you are querying from, the region you results are coming from, the geopolitical situation on that data, the entity that was matched etc etc https://developers.google.com/maps/documentation/geocoding/requests-geocoding https://developers.google.com/maps/documentation/geocoding/r... https://developers.google.com/maps/documentation/geocoding/requests-geocoding#Types https://developers.google.com/maps/documentation/geocoding/r... Don't forget entities in side of other entities like businesses within a mall. Don't forget that the user might want a specific service from the bank. The "bank" label doesn't tell you if they accept street traffic, have live tellers, are just an ATM or a corporate office etc etc.
  - londons_explore 3y ago
    This is easy to solve... Just publish 'views' of the data simplified for common usecases, and also offer the raw data for those who like joining 50 tables to know extreme corner cases like if the bar down the road's wheelchair accessible toilet will be open during the summertime hour shift.
- michaelt 3y ago
  From a business perspective, presumably they would like to charge radically different amounts for only slightly different queries. A realtor who stands to make $10,000 on a house sale might happily pay a few bucks to know the nearest schools, shops, bus stops, broadband availability etc for a property listing, but only want to do one or two searches per week. A lawyer closing the sale of a house might happily pay $50 for a report on flood risks and nearby planned developments, if it's the most reliable data available. At the other end of the spectrum, finding the nearest EV chargers for a vehicle navigation system? Users don't pay per search in vehicle navigation systems, even a tenth of a cent per search is too much. Companies who are willing to talk to their customers resolve this by the sales team drawing up a different contract, and maybe even a completely different pricing scheme, for every customer. But as Google wouldn't deign to talk to a customer over a mere $100k/year they don't have this option. From a practical perspective, structured map data often ends up with a ridiculously complicated schema, to accurately represent a reality where rules can be arbitrarily complicated. There are roads which don't allow 'trade or business vehicles except permit holders and taxis'; other roads change direction depending on the time of day; a junction might have some legal turn restrictions which don't apply to emergency vehicles, but some physical or logical turn restrictions which do. A schema complex enough to represent that sort of thing correctly will be hard to query.
pc86 3y ago
> but having built APIs, ensuring that users use them correctly is hard Having used APIs, I don't really care if the organization who built it thinks I'm using it "incorrectly" as long as I'm getting the data out of it that I want. As long as I'm paying for it, I honestly don't think they have the right to say I'm doing it "wrong."
- Shrezzing 3y ago
  > I don't really care if the organization who built it thinks I'm using it "incorrectly" as long as I'm getting the data out of it that I want That's the way I think about it for stable APIs. But for API that are under constant development, using it "incorrectly" often results in your feature being inadvertently broken by developers who are unaware of your use case.
- danpalmer 3y ago
  I built a checkout API. Using it incorrectly could easily result in a user ordering items they didn't want to, paying an amount they didn't expect, selecting the wrong shipping, billing the wrong card, and so on. Building the API in such a way that it was hard for clients to get this wrong was a very key concern for us. Separately though, I gave a better motivating example in my other reply here. tldr: what you might be paying for may come with stipulations that are not clear in the data – such as how up to date data is when used. Those stipulations may come through many layers of data source, not necessarily from the layer you pay.

londons_explore 3y ago

Whats wrong with "all maps stuff is in this huge bigquery table. Here are a bunch of example queries to get you going." SELECT business_name, business_phone FROM pois WHERE business_type = 'bank' and place_review_count > 10 ORDER BY distance(Location('New York'), location) ASC LIMIT 10; Doesn't seem particularly hard for users to use 'right' - most people using an API will have some technical background and be able to use that.

danpalmer 3y ago
Example, purely hypothetical for this scenario, but based on a real experience I had recently... What if there was a data source that went into this from a third party? What if that third party had requirements about the timeline of removing data? This could be because it contained user-generated content and something was found to be offensive or even illegal, or it could be because it contained something proprietary that needed to be correctly licenced, all sorts of possibilities. If you provide a data dump, you then need any integrators to add a data refresh process. That's an additional step that many won't do. Now you can't honour contracts or potentially legal requirements. Sure you can document this, sure you can put it in contracts, but that may not be enough.
amichal 3y ago
"map stuff" is much harder to understand than your query implies. As an example Have you tried understanding all the possible things that you can get in 'address_components' depending on the input params, the region you are querying from, the region you results are coming from, the geopolitical situation on that data, the entity that was matched etc etc https://developers.google.com/maps/documentation/geocoding/requests-geocoding https://developers.google.com/maps/documentation/geocoding/r... https://developers.google.com/maps/documentation/geocoding/requests-geocoding#Types https://developers.google.com/maps/documentation/geocoding/r... Don't forget entities in side of other entities like businesses within a mall. Don't forget that the user might want a specific service from the bank. The "bank" label doesn't tell you if they accept street traffic, have live tellers, are just an ATM or a corporate office etc etc.
- londons_explore 3y ago
  This is easy to solve... Just publish 'views' of the data simplified for common usecases, and also offer the raw data for those who like joining 50 tables to know extreme corner cases like if the bar down the road's wheelchair accessible toilet will be open during the summertime hour shift.
michaelt 3y ago
From a business perspective, presumably they would like to charge radically different amounts for only slightly different queries. A realtor who stands to make $10,000 on a house sale might happily pay a few bucks to know the nearest schools, shops, bus stops, broadband availability etc for a property listing, but only want to do one or two searches per week. A lawyer closing the sale of a house might happily pay $50 for a report on flood risks and nearby planned developments, if it's the most reliable data available. At the other end of the spectrum, finding the nearest EV chargers for a vehicle navigation system? Users don't pay per search in vehicle navigation systems, even a tenth of a cent per search is too much. Companies who are willing to talk to their customers resolve this by the sales team drawing up a different contract, and maybe even a completely different pricing scheme, for every customer. But as Google wouldn't deign to talk to a customer over a mere $100k/year they don't have this option. From a practical perspective, structured map data often ends up with a ridiculously complicated schema, to accurately represent a reality where rules can be arbitrarily complicated. There are roads which don't allow 'trade or business vehicles except permit holders and taxis'; other roads change direction depending on the time of day; a junction might have some legal turn restrictions which don't apply to emergency vehicles, but some physical or logical turn restrictions which do. A schema complex enough to represent that sort of thing correctly will be hard to query.

pc86 3y ago

> but having built APIs, ensuring that users use them correctly is hard Having used APIs, I don't really care if the organization who built it thinks I'm using it "incorrectly" as long as I'm getting the data out of it that I want. As long as I'm paying for it, I honestly don't think they have the right to say I'm doing it "wrong."

Shrezzing 3y ago
> I don't really care if the organization who built it thinks I'm using it "incorrectly" as long as I'm getting the data out of it that I want That's the way I think about it for stable APIs. But for API that are under constant development, using it "incorrectly" often results in your feature being inadvertently broken by developers who are unaware of your use case.
danpalmer 3y ago
I built a checkout API. Using it incorrectly could easily result in a user ordering items they didn't want to, paying an amount they didn't expect, selecting the wrong shipping, billing the wrong card, and so on. Building the API in such a way that it was hard for clients to get this wrong was a very key concern for us. Separately though, I gave a better motivating example in my other reply here. tldr: what you might be paying for may come with stipulations that are not clear in the data – such as how up to date data is when used. Those stipulations may come through many layers of data source, not necessarily from the layer you pay.