krsyoung

8 ms·

1.
by krsyoung 8y ago
Very cool. We're facing this common problem where endpoint consumers go query-happy with GraphQL seeing as it is so easy to pull a large amount of data (or trigger a large number of operations). It is currently very unclear how much l
2.
by krsyoung 10y ago
All the more motivation for API Providers to publish their specifications so that IDE integrations like this are effective!
3.
by krsyoung 10y ago
I still lean heavily on the framework to help with the API aspects (i.e. Rails, Sinatra, Express, Flask ...). I now consistently (at least in my mind) document the APIs via Open API Specification (swagger) and use that for documentation. F
4.
by krsyoung 10y ago
Do you think that we need to standardize on extensions? The blog post makes it clear that there is room to add additional information to the OAS document ... the question would be where to draw the line? Maybe there could be "groupin
5.
by krsyoung 10y ago
For Web APIs OpenAPI Specification has been a great resource for internal and external projects. With viewers like https://github.com/Rebilly/ReDoc/ it gets pretty easy to take the spec and generate something ple
6.
by krsyoung 10y ago
There are many great options in the list but with the state of industry and the large number of APIs coming out each year Google is still a great place to start! Curious if folks perform their initial search on any of the sites above or if
7.
by krsyoung 10y ago
My take is that Hitch is there to help developers stay informed (via push vs pull) about changes to APIs they are interested in and then to provide a forum to discuss those changes. I think the "marketplace" piece (i.e. Browse AP
8.
by krsyoung 10y ago
Hitch looks like a slick iteration on the API Changelog. Any plans to support the ability to search for APIs? Also curious how Hitch would look if it could more easily detect changes via API providers providing a more formal specification
9.
by krsyoung 10y ago
Good point, think they are broadly used? My experience with the SDK generation has been hit or miss but the intention is good!
10.
by krsyoung 10y ago
I agree with this post. I very rarely consider using a service's API without a client library. Taking the load off authentication and marshaling is incredibly valuable in my development workflow. Granted, sometimes simple REST endp
11.
by krsyoung 10y ago
Definitely there are many benefits to having API specifications available (SDK generation, testing, etc.) especially if they can come from the providers as an alternate from human readable documentation. Seems like the challenges presented
12.
by krsyoung 10y ago
I only need one API for TechCrunch: https://apiharmony-open.mybluemix.net/apis/550ad2f16170695ca...
13.
by krsyoung 10y ago
You blew my mind a little bit there ... so you're introducing the notion of a super light-weight subscription / payment system to sidecar the API specification itself? This something that would make sense with state-less services
14.
by krsyoung 10y ago
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
15.
by krsyoung 10y ago
First, it is too bad that you spent weeks and probably didn't find the "right" solution (because it doesn't seem to exist). Second, I like your enthusiasm for specs from code ... the problem (opportunity?) today is that
16.
by krsyoung 10y ago
Spidler, what you show is nice, to the point documentation for human consumption. The API specification mentioned is related to things like OpenAPI Specification ( http://swagger.io/specification/ ) or RAML ( http:&#x2F
17.
by krsyoung 10y ago
A possible reason is the fear of losing intellectual property. Providing a machine readable format makes duplication much easier (although you'd still have to deal with the implementation). The funny part is that the Oracle vs Google