Here is a link to an article we wrote: https://keenethics.com/blog/llm-randomness-problem It has way more details, but for some reason, I can't post it on HN.

After you click on "Custom Introspection" card you will see "Copy Introspection Query" link. Just click on it and query will be copied into the buffer.

Thank you!

Definitely yes, it would be great to see Voyager as a part of graph.cool. It's our first React+Redux app so we need a few days to do refactoring, more details here: https://github.com/APIs-guru/graphql-voyager#contribution

After that, we are happy to assist you with an integration. Feel free to contact us on GitHub or directly https://apis.guru/about/

Thanks Ivan. We will be in touch for sure. Let me know if you ever come to Berlin :-)

Thank you for making your GraphQL API publicly accessible. Can you suggest a better name to be used in our demo?

BTW. We also included it in our list of public GraphQL APIs: https://github.com/APIs-guru/graphql-apis

You could call the schema the Digitransit schema or the OpenTripPlanner schema. The best link for documentation is this (or a parent directory): https://digitransit.fi/en/developers/services-and-apis/1-rou...

For the list of endpoints, we offer three public endpoints ourselves: Digitransit HSL - Transit routes, stops and realtime schedules from Helsinki Regional Transport Authority, Finland: https://api.digitransit.fi/routing/v1/routers/hsl/index/grap...

Digitransit Waltti - the regional public transport authorities in Finland: https://api.digitransit.fi/routing/v1/routers/waltti/index/g...

Digitransit Finland - includes long-distance route data from Finnish Transport Agency: https://api.digitransit.fi/routing/v1/routers/finland/index/...

Good catch! Just added the LICENSE file. https://github.com/APIs-guru/graphql-voyager/blob/master/LIC...

It was our initial goal but we decided to proceed with smaller steps and that's why we've released this MVP.

It was a joke to make article easy to read.

> people using GraphQL[1] more these days

I fully agree. That's why we also maintain a list of GraphQL APIs: https://github.com/APIs-guru/graphql-apis

> solves the problem of API schema discovery because it's one endpoint with built-in introspection

You're absolutely right. We plan to do a few interesting projects around GraphQL. Subscribe to our blog to not miss announcements :)

Hi,

I'm the author, and I definitely know about Swagger/OpenAPI. By coincidence, I'm maintainer of the collection of 250+ Swagger specs for public APIs: https://github.com/APIs-guru/openapi-directory

But I have learned the hard truth over last two years: API catalogs aren't scalable solutions for API discovery. That's why I'm pushing this.

P.S. it is pretty easy to generate Schema.org type based on Swagger/OpenAPI spec.

> I'm maintainer of the collection of 250+ Swagger specs for public APIs: https://github.com/APIs-guru/openapi-directory

Ah cool, thanks for the link and effort. Will have a look at it as time allow.

> It is pretty easy to generate Schema.org type based on Swagger/OpenAPI spec.

Do you have any example or gist of a snipped of code to accomplish this?

> API catalogs aren't scalable solutions for API discovery. That's why I'm pushing this.

But does the API catalog not enable auto discovery? Agreeing you maintaining a list is not scalable.

In case this helps, the menu for apis.guru doesn't seem to be working on my iPhone 6s in Chrome or Safari. Actually, it just doesn't work on the homepage. It works if I go to the Browse APIs page.

Thanks! That helped! Fixed now

> But I have learned the hard truth over last two years: API catalogs aren't scalable solutions for API discovery. That's why I'm pushing this.

Minor critique but the word "discovery" particularly in terms of service oriented is heavily overloaded. It took me a little while to understand what the article meant by discovery and I'm still not entirely sure I do.

Do you mean this discovery: https://en.wikipedia.org/wiki/Service_discovery or do you mean a discovery more in the human sense (ie a consumer search directory listing API services)?

Would you mind to share a link for that? I am very interested as I work on different projects with swagger apis.

Here is the main site: https://apis.guru

And here is github repo: https://github.com/APIs-guru/openapi-directory

thanks a lot!

I think API owner need to see some value in publishing spec. And SDK generation, not a strong argument for publishing since it can be done on API owner side with more control and better quality.

IMHO key component here is automatic integration, you simply publish a link to your spec and you magically have integration with a number of 3rd-party tools/services.

I currently work on catalog which does exactly this, and you can see list of integrations here: https://github.com/APIs-guru/api-models#existing-integration...

IvanGoncharov, you've done much work in this space in trying to innovate around Web APIs (thanks for that!).

I think realityking nailed it in terms of the API community needing to define compelling use cases. The catch 22 here is that it is hard for people to innovate around API specifications when they are so hard to get! Per the SDKs ... what if there was a NPM.org or rubygems equivalent of high quality SDKs that get automatically generated whenever I push a new API specification? That seems like it could be cool.

And your example of automated composition is fantastic! Curious if you are able to share how much work it is for you to get access to the specifications in order to make this possible? If we invented a common practice to publish something like api.company.com/spec.yaml could you have spent a lot more time on making cool integrations vs mining specs?

Per the SDKs ...

If you've a Swagger/OpenAPI spec, you can use Swagger Codegen (https://github.com/swagger-api/swagger-codegen), a free and open-source project, to generate API clients (SDKs) in C#, Ruby, PHP, Java, ObjC, etc.

Here is an example: https://github.com/wing328/petstore-php

You can also use Swagger Codegen to generate server stub in SpringMVC, PHP Slim and more.

Disclosure: I'm a top contributor to Swagger Codegen.

(To convert RAML, API blueprint, WSDL, etc to Swagger/OpenAPI spec 2.0, please try https://github.com/lucybot/api-spec-converter - an open-source converter written in NodeJS)

> The catch 22 here is that it is hard for people to innovate around API specifications when they are so hard to get!

Yes, this is exactly the problem which I try to solve with my collection.

> Per the SDKs ... what if there was a NPM.org or rubygems equivalent of high quality SDKs that get automatically generated whenever I push a new API specification?

You can run the same tool on API owner side you don't need to publish your spec for that. I did a couple of interviews with API owner and they fear to loose control over SDKs, Docs, etc.

> Curious if you are able to share how much work it is for you to get access to the specifications in order to make this possible?

No, it's public info since my entire work is open-sourced under MIT license. I try to make process automatic as much as possible, so it starts from scraping. For example, I scrape Github for Swagger specs: https://morph.io/IvanGoncharov/API_specifications When I need to filter test, example, etc. APIs and find specs for real-life APIs. But get spec source is just first step, I need to fix errors in it(~80% have them), get additional info(logo, link to API key registration, etc.). But most time consuming is update them every day. My update/convert/validation scripts not ideal so I need to manually inspect all changes.

> ould you have spent a lot more time on making cool integrations vs mining specs?

Actually not I learn a lot from it, for example, you can fix all mistakes in API owner specs. Instead, you should give them a tool which will automatically inspect API spec and output errors/warnings/recommendations/hints. Together with my friend we working on OpenAPI/Swagger linter.

If you want to discuss more here is my Skype(ivangon4arov) and Hangouts(ivan.goncharov.ua@gmail.com) or APIs.guru public chat https://gitter.im/APIs-guru/api-models

Hi @gabamnml

I'm maintainer of this API collection: https://github.com/APIs-guru/api-models Thank you for sharing a word about my project.

One thing to note is http://apis-guru.github.io/ was created as proof of concept and example of what you can do with API to collection: https://github.com/APIs-guru/api-models/blob/master/API.md So it's more like side-project to API catalog.

Adding tags is tricky since it require a lot of manual work. Go through a documentation for all 200+ APIs and manually tag them. If someone decide to volunteer for this task I created issue on Github: https://github.com/APIs-guru/api-models/issues/54

Biggest upcoming feature is "Run in Postman" button: https://www.getpostman.com/docs/run_button_ux Spoke with guys from Postman and waiting for them to open up API to their Postman Cloud.