Mainstream culture and subculture have a give-and-take relationship. Strong opinions are formed on both sides as cultural ideas shift between the underground and the commonplace. Let's explore this as it pertains to Web APIs. In the world of Web APIs, a subculture of smart, passionate people formed around REST. While some have different opinions, their approaches share similarities. REST is not a standard; it's a style. As a result of this and a spike in popularity, a branch of REST has emerged. This "pop REST" style is a fusion of traditional REST and alternative techniques.
Thanks to all who participated in last week's Webcast, API Design: When to Buck the Trend. Here are the video and slides for the session. Thanks @daniel_jacobson and @gbrail.
REST and OAuth are predominant trends in API design. Daniel Jacobson of Netflix and Greg Brail of Apigee discussed when you might need to 'buck the trend' around design and technology conventions in order to meet your business objectives.
In working with API teams all over the world, a design pattern we've seen work really well is the API Facade Pattern. We touched on the concept in the Web API Design eBook and then in March of this year we explored the API Facade Design Pattern in a bit more depth in a series of short webcasts. We've created a new eBook with the API Facade material that you can download for your favorite e-reader and will hopefully find useful.
Thanks to all who participated in the HATEOAS 101 Webinar this week. The video (~30 min.) and slides are below. Check them out for an introduction to the core principles, examples, and a look at the value of the approach for API providers and app developers. Thanks @landlessness.
We wrote an API design book! In 2009, a couple of my fellow Apigeeks (@earth2marsh & @gbrail) and I were frustrated with how many bad, inconsistent Web APIs we encountered in the world. So, we started cataloging the bad (and good) things we saw people doing to other people through API design. After three years of discussions, presentations and implementations with technologists all over the world (online & in real life), we are happy to announce the beta version of a new eBook.
Last week I flew from Doha, Qatar to Brussels, Belgium. The fella in the aisle seat fell asleep before takeoff. The road warrior code of chivalry indicates one should never wake a fellow traveler.
So I stayed in my window seat for 8 hours. After a few minutes it became obvious that my armrest (singular, my neighbor had usurped the other one) was uncomfortable. The armrest has many problems. The biggest: you can't rest your arm on it. So, why does such an obviously bad, pain-inflicting design make it into the world? And what does this have to do with REST APIs?
Last time, we looked at why you might consider complementing your API with an SDK or code libraries. In the series so far, we've covered a lot of tips and tricks for designing pragmatic RESTful APIs.
You may be asking - How do I follow all these best practice guidelines and still maintain and iterate my APIs? What should I be thinking from an architectural perspective in terms of implementing these best practices?
Add an API virtualization layer ...