Super helpful article - it’s so great to have a zoomed out view of the space.
One question that stands out to me is where evaluation at the application level should be its own category, rather than folded in to bigger groups.
1,028 karma · joined May 2, 2011
http://timrogers.co.uk timrogers at github dot com
One question that stands out to me is where evaluation at the application level should be its own category, rather than folded in to bigger groups.
As @xavdid noted, the reality is that most people won't see these headers, but it's a nice power user feature.
I definitely see the benefit of being able to easily hit the URL from a browser - although I think it's probably only relevant for unauthenticated GET requests.
Supporting many API versions in parallel definitely has an overhead from an engineering perspective - but, as the blog post says, we thought it was crucial that we unlock the ability for us to evolve our API whilst still providing consistency to existing integrators. Some form of versioning was the only way we could see to do that.
We've built some pretty neat tooling and abstractions internally to make it easy for teams across GitHub to build and test multiple API versions. We hope to publish a blog post about that in the near future.
Honestly, we found that media types within the GitHub API had just got pretty confusing as we use them for so many things - "feature previews", response formats, versions (https://docs.github.com/en/rest/overview/media-types?apiVers...). We didn't want to overload them anymore.
Just so you know, we published OpenAPI specifications for all of our API versions on GitHub: https://github.com/github/rest-api-description/tree/main/des...
We have some small changes queued up, but nothing huge or earth-shattering.
Our focus right now is on improving developer experience and consistency where we have some weirdness in our current API design that trips integrators up. Without versioning, we couldn't address those papercuts.
We plan to release the first breaking version in the next few months.
Just so you know, we don’t intend to deprecate `2022-11-28` in two years-ish - we plan to keep versions around for much longer than that. But we offer a commitment of at least 2 years for peace of mind.
We’re just aware that GraphQL is pretty different, so if we want versioning there, we’ll need to tackle it differently. (On top of that, GraphQL has some nice primitives that come for free, like deprecated fields.)
We're also in a good position today to help existing travel sellers who want to access exclusive NDC content (mentioned in the article) that they can't get through a traditional GDS.
From there, the sky's the limit really. We'll be in a great position to help anyone who wants to sell flights - new entrant or existing seller.
I'm Tim, and I lead airline partnerships at [Duffel][1] (YC S18) - although I'm an engineer by trade ;) We're building a new API platform to make it easy for anyone to sell flights (think "Stripe for travel").
We make integration simple with our beautiful REST API (no XML or EDIFACT) and allow anyone to sign up in 30 seconds, with no need to become an accredited IATA agent.
We're rebuilding the industry's infrastructure from scratch, with direct connections to 20+ airlines' systems using the new technology mentioned in the article, NDC, rather than going through the traditional GDSs like Sabre and Amadeus.
If you want to give our API a try for yourself, you can sign up on our website and book your first flight in our sandbox in less than 2 minutes.
Equally, if this sounds like an interesting problem space to you - we're hiring, so do reach out. My email is in my bio.
[1]: https://duffel.com
GoCardless is building a payments network for the internet. Since 2011 we've been focused on simplifying Direct Debit for small and medium companies (who previously had no access to it) and we're now expanding to serve the largest companies (think newspapers, utilities) and connect with existing payment systems in countries all over the world. We already support the UK and Europe and are aiming to expand to more countries over the next year.
As an engineering team at GoCardless we care most about stable, reliable, understandable code. We rely on testing and code review and a culture of frequent constructive feedback. We define and manage our own roadmap and run projects in whatever way works best for us.
Our stack: Rails, React, Postgres, Elasticsearch, Docker, Chef. We also have a bit of Go and Python knocking around.
We love learning new things and contributing back to the community. We open source everything we can[1] and regularly host meetups and hackathons at our wheelchair-accessable office in Angel. We have a weekly bookclub within the team and give internal (and external) talks about things that interest us.
Interview process: an intro call, one coding challenge, then a couple of onsite interviews (pair programming and some chats - no whiteboards!)
For more info and to apply: https://gocardless.com/jobs. If you've got any questions, drop me an email (it's in my profile).
[1] Notable examples are Statesman (https://github.com/gocardless/statesman) and Coach (https://github.com/gocardless/coach)