The initial buzz at drinks for the end of day one of API Strategy and Practice was: “Our minds have been blown.” The audience response is evident from three talks yesterday at API Strategy and Practice in Amsterdam. Presentations aimed at developers moved from a global rethink of what coding actually is (Mike Amundsen) to how to think and manage APIs as the core unit in distributed systems (John Sheehan) to a best practice daily toolkit for developers writing code and integrating APIs (Bruno Pedro).
Balancing different audience needs
At the end of the first full day of API Strategy and Practice in Amsterdam, many attendees - and those following along on the hashtag #apistratAMS - were excited by what they were hearing in the various presentations and panels. For the organizers — 3Scale and API Evangelist — creating a program that meets the API information needs of CIOs, product managers and those in business development, alongside presenting content that encourages API developers to build best practice code is a difficult balancing act. The goal is to have enough meaty conversations for those on both the business and technical sides without anyone attending feeling lost, unable to contribute, or bored.
By all accounts API Strategy and Practice has found the sweet spot for appealing to this conference audience. Presentations have focused on information-sharing and pushing the envelope on what is possible as a collective industry, rather than a conference agenda built on a series of product pitches.
For developers, the panel sessions that focused on API design and development — with talks from Paul Wright (Etsy), Michele Titolo and Colin Marc (Stripe) — and a panel on service descriptions — led by Sumit Sharma (MuleSoft) and Ole Lensmar (SmartBear) — appeared to be the most talked about and practically oriented amongst developers looking to improve their API skills.
But by the end of the first day — gauging by conversations at post-event drinks — three talks resonated the most with developers looking for a new wave of inspiration. Mike Amundsen, Principal API Architect at Layer 7, walked the audience through a history of programming, uncovering an approach called cellular automata that is used, for example, by Wolfram Alpha to drive their search engine. Amundsen heavily hinted that developers consider the concepts in von Neumann’s cellular automata thesis to understand how code should be written in a future that will see 20 billion devices all needing an API to connect with each other, and with the Internet. In fact, he proposes a ‘no code’ model, akin to how Dutch physicist and artist Theo Jansen is building self-moving Strandbeests that are made up of parts that can learn independently and work in integration.
Amundsen’s talk inspired new ideas around how API developer-providers need to think about building APIs that can function independently and can not only maintain integrations but connect and scale outwards in expanding networks as the billions of devices grows.
How to get there: Managing APIs in distributed systems
If this is the endgame for developers in the API economy, then to get there, we will need developers who are creating APIs that function well in distributed systems. John Sheehan, CEO of Runscope points to a key disconnect facing API developers: “Now we are building applications that become distributed systems, but we don't come from that discipline,” he said at the start of his talk.
Sheehan describes three challenges facing developers:
- Getting a complete picture of your application as it consumes APIs
- Managing change as various components of your distributed system are updated and changed
- Undertaking high fidelity testing.
His slide deck -- while losing the personality that makes a Sheehan keynote eagerly tweeted and thoroughly enjoyable -- includes a useful compendium of API testing frameworks available to API developers and also unpacks one of the biggest debates in API developer circles: SDKs vs APIs.
Sheehan is pragmatic enough to believe that SDKs are an essential offering that API providers need to make available: “You definitely have to have them because the prototyping stage is the most important stage for ecosystem development. You want to help developers be successful as fast as possible so SDKS are crucial for getting developers to ‘hello world’ as quickly as possible.”
He urges resources be allocated to write good SDK documentation in developer-friendly languages. As an aside, he also mentioned that one such language to consider is the new Google Go, which he believes “is blowing up and will be the next node.js.”
But for API developer-consumers looking to incorporate SDKs into their applications, Sheehan is strongly against it. While perfect for prototyping when initially designing your product, when actually building a commercial or business application, he believes developers should turn to the API, and, where necessary, create lightweight abstractions to act as the bridge between your application and the underlying API.
But first: Day-to-day best practice
Developers were also cautioned against using SDKs in Bruno Pedro’s talk, which looked at how to create and maintain “manageable code”. Pedro is the CTO of GetApp, an editor at APIUX, and is managing API Changelog which also draws in components from his import.io hack win from earlier this year. API Changelog scans API documentation to identify recent changes, while Pedro’s import.io hack monitored changes to API terms of service. Together, the new API Changelog aims to provide a resource to API developer-consumers to be able too have more confidence and trust when embedding external APIs and the underlying data assets or functionalities into their business and application supply chains. Keeping up with changes to APIs via both documentation and Terms of Service is essential, with Pedro seeing alterations happening to key API documentation “about once a week”.
Pedro says that developers need to recognize that in many ways, the API economy is still “the wild west, where anything can happen. Especially when your API is talking to many other APIs, no one knows what is going to happen in the end.” Given this context, he argues: “So it is your responsibility to at least know that if it stops working, you know it, and you know what to do.”
Pedro sees four issues as being crucial to how a developer lives and breathes best practice in their daily workflow:
- Sharing high quality API documentation that is easily trackable for changes and updates
- Consuming APIs in your application and products rather than SDKs
- Implementing facades as an abstraction layer between the API and your business logic
- Carrying out unit and integration tests.
Pedro uses POSTMAN as part of his workflow when testing and consuming APIs:
“Basically, it is an API browser: you enter API endpoints and it will debug those endpoints and test it against pre-set data. So I have been using POSTMAN as the first approach to testing the API. If everything is going correctly, you can export your API calls as JSON files and then convert them into an API Blueprint format, which is a markdown format for describing and documenting APIs. From there, I can use testing tools like POSTMAN Collection Runner to check implementation of new methods to make sure nothing fails. POSTMAN Collection Runner cannot run unattended, so I use Runscope Radar to test every hour and send an alert if something doesn’t work. That’s basically my workflow.”
Last year saw an increasing number of API events and conferences being held around the world, and this year will be no different, with ourselves at ProgrammableWeb also hosting a conference. While this is a byproduct of the growing importance of APIs in both business and developer communities, it creates a difficulty in knowing which events will provide the best opportunities to learn and network. These three talks from Day One at API Strategy and Practice show that this conference is committed to hosting the content that can help developers think more expansively about where their work is heading, situate it in context, and then help them do their job better on a daily basis. That is what makes a conference remembered long after the evening drinks are done.
By Mark Boyd. Mark is a freelance writer focusing on how we use technology to connect and interact. He writes regularly about API business models, open data, smart cities, Quantified Self and e-commerce. He can be contacted via email, on Twitter, or on Google+.