soapui-5-banner

Live Blog: API Strategy & Practice Conference

api-strat

Over the next two days, developers, designers, strategists, and marketers will be coming together at the Parc55 Wyndham Hotel in San Francisco to attend the 2nd API Strategy & Practice Conference. The first API Strat, which took place in New York earlier this year, drew a sold out crowd of more than 300 attendees.

For the next two days, I’ll be updating this post periodically to keep you all up-to-date on what the attendees (laymen and API industry experts alike) have to say about how APIs are changing the face of digital business.

I’d also like to invite any attendees to leave your own commentary and insight in the comments section below. I’ll keep an eye on the comments and do my best to routinely incorporate them in my updates.

_______________________________________________________

Update (Thursday, 8:15pm) — Future of the Web

Concluding the evening’s sessions was a five-person panel discussing the future of the Web. As entertaining as the talk was, and as cool as Mike Amundsen’s ideas are, this panel can boiled down to a few points:

And that’s the evening. Now it’s time for tasty snacks, colorful drinks, and good conversation.

________________________________________________________

Update (Thursday, 7:22pm) — Traffic and Weather

John Sheehan and Steve Marx, co-hosts of Traffic and Weather, did their first-ever live performance of their podcast for the API Strat attendees. As someone who has never listened to their podcast before, Sheehan and Marx were very entertaining and seemed to have a genuinely good time on stage. Throughout the show they had a number of good API puns, held an API confessional, critiqued a pair of articles, and poked fun at a few companies (SmartBear included). I’ll post a direct link to the podcast as soon as it goes up on their site.

_______________________________________________________

Update (Thursday, 5:35) — Keynote: Public Media Economy

In this keynote, Kristin Calhoun gave a broad look at the business side of the Public Media Market. This system, which Irakli Nadareishvili spoke about in an earlier presentation, is a cloud-based digital database built around a Hypermedia API using common open source tools.

Calhoun highlighted some of the complexity of this huge platform, mentioned a few of the difficulties that Public Media Platform, Inc. faces, and gave a few examples where the platform will be beneficial. Although she didn’t get super technical or granular in her presentation, the use cases, strategy, and processes Calhoun highlighted were quite impressive and gave a brief look into what will be possible in the future using Hypermedia in APIs.

_______________________________________________________

Update (Thursday, 4:51pm) — API Security

If this session was any representation of the industry as a whole: API Security > API Scalability. The clear highlight of the API Security & Scalability session was some of the eye-opening points that Ryan MacAurthur brought up about how vulnerable the current state of APIs really are. During his presentation, he brought up the ideal API security principals that should be considered:

  • Traffic Monitoring
  • Authentication
  • Throttling/Quotas
  • Encyption
  • Sane Design

 He then contrasted that list with another list that more realistically depicts what is happening:

  • Log Neglect
  • Where’s the authorization
  • Surgical Theft
  • I’m not in your TLS
  • Design once mentality

He really emphasized the need to bring in security people early on. This way, rather than having security just be something that forces your developers to miss a deadline, it’s something that is built into your design. Finally, he gave another quick list of what we should expect in the future of API security:

  • Hijacking Data
  • API-centric denial of service
  • Better user reputation systems (they all suck)
  • More context around transactions

 #apistrat no #scalability questions because the panel represents greater scale than most people in the room consider… — Sharif Nijim (@snijim) October 24, 2013

_______________________________________________________

Update (Thursday, 3:40pm) — Hypermedia APIs

The first talk after lunch revolved around a theme that has already come up numerous times today: Hypermedia. Each of these speakers brought their very different storytelling style to explaining their perspective on the future of Hypermedia in APIs.

Jon Moore (Technical Fellow at Comcast) – A Brief History of API-Lantis

Moore opened up the session by taking the audience back to the “Dark Ages” in API-Lantis (pre-1990). He talked about how the people of API-Lantis were stuck using carrier pigeons, with their messages being delivered via floppy disks.

Progress was slow at this time in API-Lantis. Then, all of a sudden (around 1991) a group of philosophers opened up a discussion and created something that looked like a loan distribution library for books. These philosophers changed the whole “library system” of API-Lantis, and discovered a new type of pigeon (HTTPigeon), and trained it to fly out, read the books, and then fly back to recite the book for you.

Basically Moore went all the way through the Golden Ages (1995-2003) the fall of API-Lantis (2004-) which was plagued by POX and SOAP, and questioned whether there was an upcoming Renaissance on the horizon for API-Lantis Bedtime stories aside, Moore really covered the “how we got here,” portion of the session, and challenged the audience with a few of his closing notes:

“The fate of API-Lantis rests in your hands” “I’m serious about using HTML to power your API.”

Mike Amundsen (API Architect at Layer 7) – Reusable APIs Amundsen, who authored a book on this very topic, took a much more direct approach to talking about Hypermedia in APIs. His whole presentation came down to a list of 10 things we need to STOP doing:

  • Stop mapping semantics to protocols – map to the message instead
  • Stop hiding update and query rules in human-readable documentation – put those in the message
  • Stop requiring devs to be protocol gurus – provide “accommodations” like SDKs when appropriate
  • Stop making everyone use the same object model – share message models, not object models
  • Stop describing services as single instances – Describe services as abstract classes
  • Stop baking workflow into client code – Put workflow in the message via hypermedia
  • Stop breaking other people’s code – Take the “no breaking changes” pledge
  • Stop making client devs re-code and re-deploy at random – Use “dark release” to allow client devs to update on their own schedule
  • Stop adding single points of failure – Distribute not just storage, but also execution
  • Stop pretending that the Web defies the laws of probability and physics – Obey the laws of physics

Irakli Nadareishvili (Director of Engineering, Digital Media at NPR) – Public Media Platform

Nadareishvili started off on a positive note:

“Web content management systems are broken and they all suck.”

After clearing that up, he went on to explain why they are so horrendous, backing up his assertion by pointing out how many people are launching their websites using GitHub. The meat of his presentation was an in-depth example of how he utilized Hypermedia while building the new large content platform at NPR known as the Public Media Market. The requirements for this platform are that it:

  • had to be cloud architecture
  • had get content from a lot of sources
  • had to push content to many different devices

His went into a great amount of detail in his example, explaining how he was able to achieve all of those requirements using a Hypermedia API that was broken up into three basic elements:

  • Attributes
  • Links
  • Errors

In closing, he emphatically stated that, using Hypermedia as he did at NPR, we will be able to break down the single most damning problem that APIs have, which is that they are siloed. He used Twitter’s API as an example by mentioning the fact that it is siloed in the sense that it can’t do anything with data that didn’t originate in their own database. Possibly the most telling part of this whole session was when Nadareishvili handed over the microphone and the moderator thanked him by saying:

“That was great, with real life technical examples and everything. I thought this was a Hypermedia session”

Andrew Lau (Commerce Architect at Elastic Path) – Hype

Lau started his session by highlighting the API Hype Cycle, and explained that his presentation would be broken up between a rallying cry and reality check for Hypermedia. He broke it up into the reasons to have “hope” for future technologies and “reality” of what we really need to see happen before any breakthroughs can occur:

Hope –

  • We have a history of bad API designs
  • We have been enthralled to bad API designs
  • We are not setting the API bar high enough

Reality -

  • The client developer experience needs to catch up
  • Hypermedia Implementations have to deliver on key promises
  • Enterprises are still looking for tangible business value

_______________________________________________________

Update (Thursday, 12:59pm) — APIs and the Future of Data

This session featured four experts taking about 15 minutes each to give insights and anecdotes as to how APIs will be used in coming years in relation to data. Each mini-presentation is summarized below:

Dan Lynn (CTO & Co-Founder of FullContact) –  Data Decay

Lynn really got philosophical at the beginning of his talk with his whole “there is no such thing as the present,” shpeel. But, really, his point was a very good one: We can only know about the past, and our systems can only know about the past.

The idea is that all data is based in the past – it’s just a question of how far in the past it is from and how crucial it is that you have up-to-the-second data (such as in the stock market). He pressed the idea that there is nearly-real time data available for every situation (he used an anecdote about missing his flight yesterday because he didn’t know airport security was running slow), and that, moving forward, we be utilizing APIs to collect all of that data and get it to users as soon as it is available.

As you may have guessed, he seemed to have a lot of faith in the upcoming proliferation of dynamic subscriptions.

Harold Madsen (API Director Ancestry.com) –  API Redesign

Madsen highlighted the need for a pragmatic approach to API design – referencing to Brian Mulloy in his explanation. He also made a great correlation between API design and parenting:

“It’s okay to have different styles as long as theirs some love and consistency. Consistent APIs make us happy.”

Finally, he gave some of the things he learned as a result of his team creating a new platform at Ancestry.com, including the needs to:

  • Need to obtain very clear mental model
  • Make your standards clear
  • Market your ideas
  • Get buy-in from all levels
  • Compromise as needed

Ian White (CEO & Founder Urban Mapping) -  The Future of Data

White’s portion was very focused on being able to get fine details out of big data. He talked about how his company, Urban Mapping, slices & dices all of their data and packages it in a useful way.

“Big data equals bigger granular data. The granularity of all of this stuff really matters.”

Victor Olex (Founder & President of vt.enterprise) – Resource-Oriented Architectures

Olex focused almost entirely on the pros (and, to a lesser extent, cons) of resource-oriented architectures, which he defined as: Uniform data access layer to all data assets in their unobstructed form and reading and writing and various representations. He explained that, in his belief, resource-oriented architectures will evolve with the data ways that service-oriented architectures can not, and showed a slide highlighted the contrasts between these two types of architectures.

______________________________________________________

Update (Thursday, 11:49am) Fireside Chat with Daniel Jacobson

Although he had some pretty stringent questions aimed at him during this, Daniel Jacobson, Director of API Engineering at Netflix, did a pretty good job of standing by what he has said in the past without alienating many people in the room. Throughout his discussion, Jacobson debunked the ideas that:

He was also asked to elaborate on what he thought were some of the upcoming trends that we’ll see in the API industry, and whether or not he hopes to kill them as well. Here’s a brief summary of a few of his answers.

What’s do you think is the next trend in the API industry?

  • More people are going to break down the concepts of REST.
  • Markup languages that closely align with REST are probably likely to lose value as well
  • “If I was to start an API today I would probably take this into consideration and ditch some of those things.”

What do you think about Hypermedia?

  • It’s simply a technical engineering detail that should be decided on a case-to-case basis

What do you think about the proliferation of these API-centric conferences?

  • “There’s a lot of value around these types of events”
  • The conversations are going to be different in the next couple of years.
  • We’ll be seeing more dissenting views on things like HATEOAS
  • We’ll see more interesting conversations and revolutions coming from these events

 @daniel_jacobson on next trends in APIs? most people will consume APIs on a smaller, more tactical basis. #apistrat @SmartBear — Meg Cater (@megancater) October 24, 2013

_______________________________________________________

Update (Thursday, 10:56am) — Peter Rexer Keynote

I fell a bit behind during Peter Rexer‘s keynote, but I was able grab a few of the main points he stressed before he wrapped up:

  • Use simple names
  • Provide 1 type of response (Obviously, he insisted on JSON)
  • Have a Consistent Structure
  • Hide advanced functionality
  • Don’t be beholden to purists

Rexer very much highlighted the need for simplicity – for the sake of all parties. He gave a good anecdote about how his company, box, was allowing both JSON and XML responses. In an effort to simplify, they reached out to those users who were utilizing XML and asked how upset they would be if they were forced to switch over to JSON. According to Rexer, 90% of them were completely fine with making the switch, and it ended up allowing box to shed some complexity and focus entirely on JSON.

His final, and strongest point, was against the purists of the API industry. He was even humorously warned as he exited the stage, that he may want to avoid the Hypermedia session that will be happening later this afternoon.

  _______________________________________________________

Update (Thursday, 10:33am) — Wynn Netherland Keynote

The most notable takeaway from Wynn Netherland’s (#REALTALK) keynote was the idea that you must eat your own dogfood, when it comes to APIs. Not only is this a good insurance system for making sure your API works correctly, it’s also a policy that will ensure that you build something meaningful. 

As an example he highlighted that GitHub builds all of their internal tools on their own API. In the same sense, along with being meaningful and working correctly, he insisted (quite ironically, after Pamela Fox’s points on documentation) that developers will not read your documentation, which means you have to make it as easy as possible for them to use. His point wasn’t that you should completely ignore your documentation.

It was more that, even if you put blood, sweat, and tears into your documentation, it will never be as beneficial as if you had spent that time improving the developer experience of your API – I see a theme forming very quickly here.

_______________________________________________________

Update (Thursday, 10:00am) – Pamela Fox Keynote

Pamela Fox just gave a grand whirlwind of a keynote, focusing very strongly on the importance of (what I’m going to call) the 3Ds: documentation, debuggability, and the developer experience. She had a handful of amazing one-liners (see tweets below), but what was most helpful was how simply she was able to sum up her main points at the end of the presentation:

  • You have to give a shit (about developer experience)
  • You have Prioritize the aspects of your API that will be most helpful to developers, (i.e. “getting started,”  your documentation, and your design)
  • Improve, improve, improve until you have the most experience in the world.

And, of course, her closing quote was great: “Developer experience: It matters, you should make it not suck, and I have full confidence in all of you since you’re here today.”

________________________________________________________

Update (Thursday, 9:36am) — Opening Remarks

The opening remarks by Kin Lane and Steve Wilmott were very brief, but also very telling of the intended purpose and atmosphere of this conference. Kin Lane, as he did yesterday, highlighted the growth of API use in government as a way to highlight how mainstream they have become. 

He also reiterated his prediction that, in the not so distant future, APIs will be essentially mandatory, along with websites. Lane and Wilmott were also very up-front about emphasizing that this is meant to be an inclusive event, with attendees from a wide-range of skill levels (Lane also pointed out – as Kirsten Jones did in her workshop yesterday – that his mother was here at the event).

As brief as they were, these opening remarks really have set the stage for an extremely inclusive, open-discussion event. Now taking the stage for the first keynote is Khan Academy’s Pamela Fox.

___________________________________________________

Update (Thursday, 8:55am) — Just Getting Started

After a half day of workshops, it’s finally time to get this thing underway. With breakfast wrapping up, attendees are just starting to flow into to the Cyril Magnin Ballroom on the 4th floor of the Parc55 Hotel to hear the morning’s keynote speeches by Pamela Fox(Khan Academy), Wynn Netherland (GitHub), and Peter Rexer (Box).

To give some context, yesterday’s activities consisted of six workshops, which featured some insight from Kin Lane about how the different levels of government are utilizing APIs and a hands-on demo of Swagger by Tony Tam.

Kin Lane is about to take the stage to introduce the triage of keynotes. Don’t forget to leave a comment below if you’d like to add to the conversation.

See also:

subscribe-2

Comments

  1. kryptogoloc says:

    The opening remarks always gives the game away even if they are obfuscated in a non obvious manner. However, this can be removed from the API by judicious use of proper initial factoring.

    After you have factored your model then go through a couple of phases of refactoring without even creating any code. You must re-factor your abstractions and generalisations into a perfect tier of responsibility and functionality.

    Only then can you dare to create the API. You have a perfect specification to work with and will make the highest grade code quality (A++ grade). Your APP will run the most lightly and daintily in the bounds of the CPU (it could be CPUs if you have a multi core CPU).

    It is not necessary to explicitly create UNIT TESTS if you use a Kohonen network front-end to receive events from your debugger. It takes just a few minutes of runtime in the debugger for the network to be trained to the signature of your code body. Any deviations are flagged for analysis.

    It is useful sometimes to emulate a Zener diode in your code. In fact I have a class called ZenerDiode which is a factory class to create Zener diodes in your APP. Zeners are very handy for filtering events in the API. You can set the Zener to trigger at a certain level of API pressure.

    Anyway.I shouldn’t tell you any more about this technology because someone might try to copy it.

    Keep up the great blogging work. It is very sharp.

Trackbacks

Speak Your Mind

*