Introducing Geekier, an open source & saner approach to working with APIs
1–10 of 18 posts
Re: Introducing Geekier, an open source & saner approach to working with APIs
#2I can personally vouch for Kevin and his team's work here in Berlin. It has already improved my quality of life!
Re: Introducing Geekier, an open source & saner approach to working with APIs
#3This is really starting to sound like what java / .net were doing with wsdl code generators via soap.
Devs that integrate with multiple apis know there is a problem with the wide range of implementations, from authentication to communication patterns. This makes it a pain to integration with multiple service providers. Without some form a standardization you must have an intermediary library to provide an abstraction.
Are we doing it right?? The community has recognized the problem of non-standard lightweight services to be widespread enough to create a tool to standardize communication with them.
Would something like HAL (http://stateless.co/hal_specification.html) be a start down a path where we can have lightweight services that are also self documenting?
Re: Introducing Geekier, an open source & saner approach to working with APIs
#4algorithmmonkey hit the nail on the head: this sounds a HELL of a lot like WSDL and the WS* method in general. I HATE the WS*. However, I'm not going to knock what they are doing, because it is certainly a noble effort. Could someone who is much smarter than me explain how this would avoid the pitfalls of past attempts at abstracting service layers?
It's interesting to see the approach of abstractable APIs, vs. the other way of making usage of data more automatic, via machine readable semantic markup and embedding metadata into the data structure aka linked data/semantic web.
I think its all awesome.
Re: Introducing Geekier, an open source & saner approach to working with APIs
#5Looks like the dev version of Zapier.com
Re: Introducing Geekier, an open source & saner approach to working with APIs
#6Sounds a lot like the hypermedia discussions going around....
Re: Introducing Geekier, an open source & saner approach to working with APIs
#7Looks like the dev version of Zapier.com
We really think Zapier has done an amazing job in building a gorgeous UI, easy to understand UX and gaining support from the API community. But, obviously they are really well suited for end users and not as much so (in our opinion) for devs needing to talk to a bunch of API's directly. As the need to talk to many API's was at the core of rules.io, it made sense to us to try to gain support from the community for some standards and to contribute descriptions.
Our goal is to really better support the needs of app developers needing to work with many API's rather than the API developer themselves. But we hope to gain support of both.
Re: Introducing Geekier, an open source & saner approach to working with APIs
#8I can personally vouch for Kevin and his team's work here in Berlin. It has already improved my quality of life!
Paul, thanks for your comments and support! We're excited to get the Berlin community involved as well.
Re: Introducing Geekier, an open source & saner approach to working with APIs
#9This is really starting to sound like what java / .net were doing with wsdl code generators via soap. Devs that integrate with multiple apis know there is a problem with the wide range of implementations, from authentication to communication patterns. This makes it a pain to integration with multiple service providers. Without some form a standardization you must have an intermediary library to provide an abstraction…
This is a good point that we discussed, too. While Hal, like HATEOAS is very interesting and definitely a simplification that's necessary to make our lives better, we're aiming at something different: we're trying to describe existing (ReST) APIs in a way that a single library using a Factory Pattern can turn into connections that you as a developer can use to work with that API.
We settled for the swagger format, because its very flexible, human-readable and honestly can be turned into very nice looking documentation pages.
Re: Introducing Geekier, an open source & saner approach to working with APIs
#10This is really starting to sound like what java / .net were doing with wsdl code generators via soap. Devs that integrate with multiple apis know there is a problem with the wide range of implementations, from authentication to communication patterns. This makes it a pain to integration with multiple service providers. Without some form a standardization you must have an intermediary library to provide an abstraction…
This is a good point that we discussed, too. While Hal, like HATEOAS is very interesting and definitely a simplification that's necessary to make our lives better, we're aiming at something different: we're trying to describe existing (ReST) APIs in a way that a single library using a Factory Pattern can turn into connections that you as a developer can use to work with that API. We settled for the swagger format, be…
GET http://wombat.com/resources/foo/apidoc ==> A "RESTful" resource ...
http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hyperte...