Google API Explorer | Hacker News Reader

Google API Explorer

developers.google.com

213 pointstzury37 comments

Hey, eng lead here for the APIs Explorer. Despite the site's ancient appearance, we're not killing it, and have some plans in the works. (You can see some of the work we've been doing on developers.google.com, with "Try this API" on the right [1]).

Feedback I'm interested in: What do you use the APIs Explorer for? What features would you like to see?

[1] https://developers.google.com/google-apps/calendar/v3/refere...

> ancient appearance

You mean usable and fast without needless animation like everything in material design?

You say "without needless animation"; I say "makes me, as someone with a sensory integration disorder, able to refocus my eyes to the new text more quickly." (And then someone else says "makes me, as someone with the other kind of sensory integration disorder, overwhelmed and distracted and so hinders my fluency.")

Accessibility is not a scalar; some people need things that other people don't; some things X people need hurt Y people, and vice-versa. The animations might not help you, but they help someone.

By your own argument, animations != accessibility. Animations MAY be a matter of accessibility for some people and an accessibility problem for others - real accessibility would be making it optional instead of the default.

My actual argument would be to do real usability testing to see whether either of the options (more animations; less animations) helps, on average, if made the default.

An analogy: the way we use capital letters in English helps to guide and reorient the eyes of people who are dyslexic. But English's capital letters also help in the same way—just to a lesser degree—the people who aren't dyslexic. It turns out that capital letters are just a good idea on average, like e.g. the wheelchair ramps built into sidewalk curbs.

Now, there are probably at least a few people in the world who can read English text better without capital letters for whatever strange reason. But if the average person can read better with them there, then it's better to enable them and make disabling them an option, rather than to disable them and make enabling them an option. The average person, not thinking of themselves as needing assistance, wouldn't look in the options for an "enable capital letters" option. And so the average person, who could have been helped by the assistance, would have QALY left on the table—and that's a large amount of QALY when multiplied by the number of "average" people, compared to the two groups that have specific, recognized problems that they'll know usually have solutions in options menus.

Then we should give users a choice some how? You'd think this could be a solved issue ~20 years in.

If the animation were done in pure CSS, UA stylesheets could suppress it handily.

Suggestion to improve the UX for some users by having them write CSS stylesheets? Count me it ;).

Nothing personal, but this sounded a bit surreal to me.

"UA stylesheets" is sort of an intermediary format these days; you don't write them yourself, you use a browser or browser extension or a piece of native accessibility software that generates them for you in response to your described needs.

FWIW iOS has a reduce animation accessibility option. No idea if it's somehow enforced on apps or Google voluntarily respect it in their apps though.

This is a valuable resource for developers trying to integrate with google services. The API explorer is the what I go to after reading the API documentation. The Google API explorer is a lot more usable compared to some of the swagger/openAPI based ones.

Have you guys considered switching to swagger-ui (https://github.com/swagger-api/swagger-ui)?

This is not to say Google API explorer is bad or swagger-ui is better.

Disclosure: I'm top contributor to Swagger Codegen but not Swagger UI.

Great resource, I've used this often from client computers to look at some basic data before offering support.

I use most of the advertising related APIs on a daily basis. I am very happy that I can take a look at a client's account, at the client's desk, before access is provided.

An API explorer for Doubleclick for Publishers seems to be missing from the list, I presume due to the increased complexity of DFP it was not included, are there any plans to include DFP in here?

This site loads incredibly slow. What is actually happening in between the time I get a Google frame with blank content and the content finally appearing?

The extreme sluggishness is a problem I've also noticed on the Google Careers site.

I would really like to see sample inputs. Or for example, when exploring an api funciton on i.e. the NLP landing page, why not have an "Export this to the API explorer"?

Very nice resource! Casually browsing on iOS I noticed it crashes the tab...

Features would you like to see:

* be able to display my own APIs, not just Google's

* make it open source, under a suitable license.

Swagger/OpenAPI's UI is great & open source. It is based on the OpenAPI standard. Why isn't APIs Explorer doing it too?

-Download a postman collection.

-Comments per api. There is valuable information in the section of REDIS docs

Minor nits:

- if I close the try-it-now side bar, it comes back every time I click on a new API

- The try-it-now is slow to load

- the side nav is poorly discovered. It's hidden by the Try it Now side pane.

Full disclosure: I lead the overhaul and modernization of my companies developer documentation site.

I would remove 'Google' from the sorting. So you don't have that big amount of APIs once you scroll down a bit starting with Google, at that point Google is a filler word - I would expect Google Ad Experience to be sorted with the other Ad APIs.

Maybe a google history type integration. Logged in, show what searches I have done that brought me to what api pages.

They should add one column to display the expected time before they kill the service

Even though it's becoming the same old google joke, such a well placed burn must have taken down a whole data center.

Can we just ban pointless snark like this? No matter if it's directed at Google or Apple or whatever.

It just has no substance and is tiresome to read over and over again.

You're right actually, but I still think they could add some indications about the support time of a service. Like some guarantee that the service will be around for at least 3/5 years. Not necessarily in this API explorer, but for all their products.

The joke is tired, but there may be a germ of an idea there. Maybe various SLA metrics could be added in a standardized way.

Hey! I made this in ~2012 (2011?) or so, and it's still one of my greatest accomplishments. Glad people still use and like it. :-)

Thanks JasonH!

I used API Explorer to learn the API of a GApp I had to integrate in a customer's web app. It's OK but I wished for a couple of improvements:

1) I failed to notice some errors and messages because they appeared below the fold and nothing close to the submit button hinted me that something happened. Furthermore having to scroll up and down to type and to check the results is far from optimal.

2) It should at least nudge the API developers to write documentation and make it appear in the page. I was left too many times wondering what the attribute names picked by the developers were meant. They eventually sent me a Google Doc. Compare this to Swagger's in page hints and examples.

Can you really trust any of these to exist long-term?

You can probably group them into two categories: APIs that Google makes money from, and those they don't. The former probably will stick around, especially the ones having to do with Ads.

And why would I put in time learning these APIs if I have no guarantees they will continue existing?

That's pretty much true of any service you don't control.

That's more true for Google since very few of its product are actually making money. Everything comes from advertising, which comes mainly from Google search. This they have no real incentive to keep any product that doesn't display ads.

A solution could be to let the users pay a little money for google services (and avoid tracking / use of its data for advertising? )

Google's "other revenue"[0] for Q3 was $3.4 billion of the $27 billion it made that quarter. Other revenue is mainly Play, Cloud, and Hardware. So I'd say Google is making a lot of money from other avenues.

[0] https://www.sec.gov/Archives/edgar/data/1652044/000165204417...

Google is the master of leeching and rent-seeking.

Just as they pit advertisers against each other to drive up prices for impressions on third party sites, for which they keep a large middelman fee, they use the same tactics on Google Play. Developers get to bid on the #1 search result spot, while Google is milking them for 30% of gross revenue for providing a rather abysmal ZIP file download service. They are only able to charge such high fees because of the exclusivity and network effects from being pre-installed on every GMS Android phone.

Other examples of similar rent-seeking platforms are Apple App Store, Windows Store, Steam.

Many Google APIs either offer paid premium tiers (eg. Maps) or are pay per use (all Cloud APIs).

They have plenty of commercial products and Google Cloud Platform is likely to make more money then the entire ads business in the future.

and the ones you do...

Reply on news.ycombinator.com