ProgrammableWeb’s vendor-neutral, developer-focused conference, APIcon, began its second installment this morning in London. After a successful event in May in San Francisco, APIcon UK has taken the format across the pond to European and British developer communities.
“ProgrammableWeb and APIcon content are in lock-step,” said David Berlind, executive editor of ProgrammableWeb, opening the conference this morning. “We are making sure we are hitting the new themes that matter most to our readers. For example, we have a session on linked data, which in my mind is the wind in the sails of the semantic Web. We also have a strong focus on API design, crypto-currency, the Internet of Things and security. My keynote tomorrow morning shows you why API security should be your No. 1 priority.”
All APIcon UK sessions are being videotaped and slide shares will be uploaded. Videos of each session will be published on the ProgrammableWeb YouTube channel, shortly after the event.
The conference mirrors the May San Francisco event, with two main tracks: developer workshops and API provider sessions. The final session on Friday will focus on a new format: a hand-selected innovation showcase, “bringing you new things to think about in regards to your API strategies,” Berlind said.
Machine Learning: Twitter Buzz
Morning sessions focused on machine learning and API description languages.
Separate reports will be posted on Bootstrapping Machine Learning author Louis Dorard’s talk on leveraging predictive APIs, and on Jon McLoone from Wolfram Alpha, who spoke about using computation to make powerful APIs.
The morning sessions on machine learning saw the most Twitter buzz, with developers eager to learn more about how to incorporate these powerful new techniques and API tools into their applications.
API Description Languages: RAML Ascending
Two morning talks also focused on the rise of RAML: Uri Sarid, CTO at MuleSoft, the parent company of ProgrammableWeb, and member of the RAML Workgroup, walked developers through how RAML creates a design-first API model, while Laura Heritage, director of API strategy at SOA Software, compared RAML and Swagger, explaining her preferences for RAML and sharing some insights from her enterprise customers.
“APIs are business drivers in themselves,” Sarid explained at the start of his session on Delight-Driven Development. “Big initiatives inside business are being powered by APIs,” he said, listing:
Mobile: This is a big spend in business and is all powered by APIs.
New revenue channel: For example, New Zealand Post has remonetized their addressing and billing service by partnering with banks, using an API.
Innovation: Businesses are discovering a single API has multiple use cases and opportunities.
Now APIs are being tied to business objectives, are budgeted and owned within a business and are being regarded as products in their own right.
Because of this context, Sarid said, businesses need to build APIs that create an experience where both in-house and external developers say, “Yeah! This is the API I have been looking for!”
Comparing RAML and Swagger for the Enterprise
Following Sarid’s overview and walk-through, Heritage then held Swagger and RAML up side by side to compare the adoption of an API description language in the enterprise.
“Enterprises are able to use RESTful APIs now because description languages enable APIs to be governable, shareable and readable in the enterprise,” she said.
While Swagger and RAML share many features, to Heritage’s mind there were two standout reasons for RAML use among her enterprise customer base.
First, if the APIs need to be created with input from across the business operations, RAML’s approach to description can help anyone understand what the SAPI is about. “If you need to share your API descriptions with kind of tech-savvy but technically limited people, RAML is a better approach,” Heritage said.
Second, choosing a language can come down to acknowledging how your team works: “If your team designs your API before you code, RAML has more utility,” she said. However, Heritage also noted that while both Swagger and RAML are able to auto-generate documentation from code, Swagger has more code libraries available and therefore may meet some team cultures better.
Heritage shared her experiences creating an API description in both Swagger and RAML, summing up her thoughts from each.
Aside from her own experience, Heritage sees her SOA customers also more interested in RAML: "Enterprise customers at SOA Software are leaning toward RAML because of the richness of the specification, with inheritance and traits, for example. The way that RAML helps enforce standards is also helping enterprise consider RAML for their APIs."
With Swagger, API Blueprint and RAML all vying to offer new features in their API description languages, it may still come down to personal choice or business policy decisions. This morning’s sessions helped many of those who have still not begun to work with descriptions to begin considering why to add them to their API design life cycles. Although as one APIcon UK attendee pointed out, the lack of discussion of hypermedia API description languages may be doing a disservice to enterprise. Debate continues…