This guest post comes from Ole Lensmar, the creator of SoapUI and Chief Architect at SmartBear Software. Follow him at @olensmar
Another month – another API event! This time in my hometown Stockholm – what more could you ask for? Spring weather perhaps? We may have to wait for better weather until the fall conference, which will feature talks from ProgrammableWeb’s own Adam DuVander and John Musser. For now lets recap what we saw at the inaugural Nordic API event.
Due to high demand the conference was actually held twice within one day. I was in the morning session together with around 100 other API aficionados – excitement was in the air through all sessions. Unfortunately I missed the welcome talk, but got there in time to listen to Andreas Krohns’ overview of the API domain. Andreas is one of the driving forces in the Nordic API movement, and both his expertise and passion for APIs was evident in his talk that covered everything from business adoption to technology religion. He ended with raising a warning sign; “there will be a backlash” – and although I definitely agree it felt a little like telling your kids they will have a stomach-ache if they eat too many sweets – we want to have fun! Now! J
Next up was Gustaf Nilsson Kotte to talk about Hypermedia HTML APIs and adaptive web design, which basically boiled down to
1) Embracing the Hypermedia APIs paradigm
2) Using HTML as your API media format
3) Using adaptive web design techniques to adapt the HTML to different clients/browsers
Although the case made was compelling, these points failed to win me over – primarily because I just can’t see this to be realistic for more complex APIs; the simplistic example given at the conference was cool, but imagining an API with hundreds of operations/resources, massive representations and complex business logic implemented this way makes me all nervous – I just don’t think it scales as both UIs and resources become more complex. Given the attention Gustaf has gotten for his ideas, one should definitely not count this out though; if understanding and adoption of Hypermedia APIs proliferates this approach does offer some interesting advantages.
Next up was Ronnie Mitra to talk about a developer-centric approach to API design. He introduced the idea of DX – Developer Experience as opposed to UX for User Experience – as developers are usually the hands-on “consumer” of an API – and gave advice that I think resonated with many in the audience. It doesn’t matter if you love SOAP; if your API consumer is building mobile apps, then perhaps REST is a better choice. It doesn’t matter if you prefer OAuth – if your target domain is heavily invested in SAML-related security standards then that’s what you’ve got to do. You get the idea. J
During the coffee break, I had the opportunity to talk more with Andreas about what he is seeing in regard to API adoption. Frankly (and not surprisingly) – it’s all over the place. He is involved in everything from API business strategies to technology and implementations – sounds like an awesome job to have for someone so on top of “the APIs of things” J
After the break were the talks I actually looked forward to most; one of my concerns with APIs meeting the needs of the Enterprise has been how the REST community will address security and QoS-related aspects of REST APIs. Specifically, for message-level security beyond SSL (encryption, signatures, etc), how can we avoid treading into the waters of WS-(*)? Well, as Travis Spencer put it when I talked to him in the break before his talk; the question isn’t if WS-(*) can be avoided – it’s too late for that. The question is how do we get out of it without messing things up for future API providers and consumers.
His session focused on giving an overview of the multitude of security-related standards within the REST community, including:
Unfortunately these are all governed by different entities, many of them are related or overlap each other, and most have no clear recommendations on how to use them. In analogy with what OASIS has done for WS-Security, it would be nice if these could be gathered together with clear guidelines on how to use them, i.e. a “REST-SecurityProfile” in analogy to the WS-Security Profile from OASIS. I think getting this right (together with API governance, policies, SLAs, etc.) is going to be one of the key enablers for enterprise REST API adoption. Since that ball is just starting to roll, we still have time, but we know from WS-(*) that it has to be done decisively and swiftly. Otherwise the risk that organizations come up with “standards” of their own instead of waiting for general standards to emerge is imminent.
The presentation from Hans Zandbelt followed up with a practical dive into federated identity management with SAML and OAuth – currently at the core of federated logins / identity and SSO solutions. Hans gave hands-on examples of how this works both at the web/user and the backend/API layers. Despite of its complexity, this is something that API architects will have to develop a deep understanding of to meet their API’s business requirements for both security and openness.
Although it was just 3 hours, it was definitely packed with useful information for most of us. Again a huge thanks to Andreas Krohn, the sponsors and the fantastic speakers for a worth-while event – of course I’m already longing for the follow-up later this year. Read all about that, the speakers and sessions, etc… at http://nordicapis.com/