lifecycle-management-api

Discussing the Past, Present and Future at Nordic APIs

Nordic-APIs

Nordic APIs – just the name holds so much promise; APIs – the north – in all their beauty. And I was not lured alone; there were at least 150 people gathered at the lush conference venue to enjoy emerging business models, enterprise security policies, the internet of things, stimulating discussions, and good coffee.

How Open is Your API Future?

After the opening welcome, Adam DuVander got the party going with an extensive overview of where APIs might be going and, more importantly, where they come from. The context he gave started with the first APIs published by Google (Search via SOAP!) and Amazon in the early 2000s and moved up to the latest APIs and trends (definitely not SOAP). This served a great reminder to us all that APIs really are not that new – and that many have been struggling to find their way before us – a way that for many of us now may be obvious.

Evident from many of his examples was that APIs are more and more a part of a business strategy – and as such might not always play out as an enthusiast community would like them to. Adam gave several examples from the past years where APIs have either been discontinued or restricted to create a better alignment with the associated product offering – often frustrating (or infuriating) their end users. Also, Adam provided an insightful answer to the question “What makes an API Open?” – the answer being “When it’s not closed”. High Five!

Building a DX based API Strategy

Next, Ronnie Mitra did a very memorable intro to his session on “Developer Experience.” With his back to the audience he read (quietly) from a badly phrased and formatted text – we couldn’t believe what we were seeing. He timed it perfectly, and transitioned to a big “Just Kidding” slide just when most of us had started accepting the dread of the remaining 20 minutes lying ahead.

This intro served as a great example of his main theme: How important experience is for our adoption of underlying content, which of course is equally true for APIs.  If the experience isn’t in line with the consumers expectations, chances are high they will look for an alternative that provides them a better on-boarding experience even though the functionality or data provided by the API might be exactly what they need. Documentation, accessibility, metadata, standards-support, nomenclature are all key to forming that user experience.

Ronnie also made an important point in that you have to know your target audience; don’t build your API for the enthusiast API junkie (“Josh”) unless he is really your end user – make sure your choices when selecting technology, nomenclature, etc are aligned with your primary personas – not the general API crowd.

Scaling API Re-use, Security, Integration Across Multiple Properties

Peter Logan was next – first in a large number of sessions that targeted security and identity related issues for APIs – it’s quite obvious that security aspects of APIs need to be solved in a scalable way as large information brokers start making more and more of their core assets and data available via public APIs. Unfortunately the number of standards in this area is starting to become quite overwhelming – and it can be hard to understand the difference between different versions of OAuth, OpenID Connect, etc.  I’m hoping there will be an open effort to bring this to the enthusiast community as well as to the enterprise – so we don’t end up with a mess similar to the WS-* stack (more on that below).

The Why and How of Testing APIs

After the break I had to catch up on some work issues but was back in time for Matti Hjelms talk about the How and Why of testing APIs. Just like security, quality is something that the API crowd is going to have to “grow up” to, and Matti’s talk gave us all a healthy reminder of how important (and fun!) real testing actually is.

He also reminded us that, although developers are often using ad-hoc tools and code-based techniques (TDD; BDD, etc) for testing their code and APIs, most developer aren’t’ testers by heart. The sooner you hire a pro tester to your team – the sooner your customers are going to get a better end product (read more about my take on this difference in “The Art of Testing”).

Business Models in an Internet of Things

Finally the panel discussion before lunch talked about (or at least attempted to talk about) Business Models in an Internet of Things. To be honest, I don’t recall any real take-aways from this otherwise interesting session – perhaps it is still too early to see how IoT will translate into viable products and solutions that consumers are prepared to pay for (or so I thought, more on that below).

That was it for day one for me, which was too bad as there were many really interesting topics lined up for the afternoon sessions. Better planning from my part next time.

Securing APIs using Modern Standards

Thursday kicked off with another two sessions focusing on identity and security. In one of these, Travis Spencer compared the “Neo-Security stack for APIs” (SAML, OpenID Connect, OAuth, SCIM, JWT, JWK, etc) to the WS-Security stack for SOAP that was born out of similar needs at enterprises adopting SOA principles.

I find this interesting; will this security stack have a similar effect on the REST community as all the WS-* standards did on the SOAP crowd (i.e. scare them away)? Or will the community rise to the challenge and actually adopt these standards and incorporate them into their frameworks and solutions? Although the later would surprise me – that’s the one I’m hoping for. These standards solve a real-world problem that might just as well get solved in a coordinated way – with open standards providing the foundation.

The Unconference Sessions

After this came the “unconference,” a number of sessions on topics suggested by conference participants. I attended three sessions, the first on API scalability, the second on APIs for non-programmers, and the last on how to detect changes in APIs. Surprisingly the last turned out to be the best.

Mehdi Medjaoui nicely led an open discussion with a small group of mostly developers on how you can guard yourself against “unexpected” changes in APIs that you are consuming. As Mehdi seemed to be preparing a summary of the discussion himself, I will only outline some of the suggestions:

  • Monitor API metadata descriptions for changes (via automated diffs)
  • Select only API providers that have a well-communicated versioning strategy
  • Create functional tests that mimic your usage of external APIs and set these up as production monitors

The discussion was great – and the subject highlighted something that seemed to be a real-world problem for the participants. Thank you!

Connecting APIs to Enterprise Mobile App Dev

After lunch I attended another session by Peter Logan, which added more focus on the importance of security when building APIs for your enterprise. It was great to finally see some focus on more than authentication, authorization and identity.

Peter talked about the equally important domain of security vulnerabilities and that you need to guard for them; intrusions, cross-site injection attacks, boundary attacks, etc. Unfortunately, this aspect of API Security is often overlooked, but given that your APIs often expose data or functionality core to your business this is nothing to take lightly – the price to pay can be high, as we have seen several times of the last years (Facebook, Twitter, PSN).

API’s and Performance – The Befores and Afters

Next to admire was my old friend and partner in crime Niclas Reimertz. He did a splendid talk on a method for identifying performance issues in API-based system, based on a real life scenario.

Not only did he manage to present a somewhat scientific 7-step approach to getting to grips with performance issues in production APIs, he also had the best looking mind-maps I have ever seen in a presentation. Awesome!

The Event Horizon – Designing API’s for the Internet of Things

The second day was edging to its end but just like a good New Year Party, it ended with a bang. The session by Holger Reinhart on Designing APIs for the Internet of Things was a real eye-opener for me. Not only did it open my eyes to the MakerBot movement (very cool), it also broadened my mind in regard to what the Internet of Things can accomplish, in form of the Good Night Lamp (even cooler) – a great example of how someone thinking outside the box created a novel application that extended at least my conception of what IoT might bring us on top of connecting our existing home devices.

Holger concluded by highlighted the fact that HTTP and synchronous APIs are going to see plenty of competition from more asynchronous counterparts; WebSockets, pubnup.com, XMPP, COAP, Stomp, etc. – often extremely simple protocols adhering to a publish/subscribe approach that makes great sense for disperse devices as it paves the way for a more “event-driven” Internet of Things, which has many advantages – actuality and bandwidth requirements to name a few.

Making a Brand Programmable

After the final break a very different but equally cool presentation by Eva Sjökvist on how to make a brand programmable. Not only had her company made the most impressive promotion videos for an API that the world has ever seen – she also showed a builder-like approach to URLs which I had never considered or seen before. In her case it was used for filtering search results; so instead of filtering a list of item returned from a GET request with query arguments, as in for example:

GET http://www.somehost.com/hotels?pool=yes&beach=yes&month=January

a more “fluent” approach could be used to express this as

GET http://www.somehost.com/hotels/with/pool/with/beach/in/January

(a fictive example based on their model)

I don’t think this aligns with a strictly REST-ful approach, but boy is it delicious!

All too soon the conference now came to an end (as Kin Lane was ill unfortunately), and Andreas Krohn and Travis Spencer did a great wrap-up expressing their gratitude to the audience, speakers and venue.

But honestly guys – if there is anyone deserving thanks it’s you two for pulling this together a second time: once again you did a fantastic job at gathering the right mix of people and topics to propel the Nordic API community forwards – and make us all look forward to the next Nordic APIs. Thank you Andreas, Thank you Travis!

/Ole

See also:

01dbfdd8-264f-4b83-85f3-ec9ec1309684

subscribe-3