Lots of Passion
This is my major take-away from the conference; the API community is having a blast! Geeks, hipster coders, architects, business developers, senior marketers, sales and product owners - they were all there gathered for the feast - and they were feasting together. Historically I have often seen a divide; geeks are passionate, business is skeptical- or business is raving and the geeks don't get it. Here though they are all rowing in the same direction - helping and complementing each other - it was awesome to behold, and holds great promise for future developments in this movement.
Of course - there was quite a lot of competition as well. For example the panel discussions on API Management and PaaS sometimes had a "mine is bigger than yours" component that was quite enjoyable for the audience - but surely challenging for the participants. The players are both startups and existing enterprises that have adapted their offerings to the API space, both have their pros and cons; who will win in the end is definitely still out in the open.
Swagger FTW
Swagger is a metadata format for describing REST APIs, and as such it can be used to generate code, documentation, tests, mocks, etc. It's an open-source project created by the wordnik folks, now hosted by a spinoff named Reverb. When I first encountered it a couple of months ago I was a bit surprised given the existence of WADL which is an older standard that solves all the same problems. Given the situation at hand, Swagger has definitely succeeded where WADL has failed; it has been adopted by many of the API management and tool vendors at the conference, and it’s looking to be the primary choice for many REST projects out there (based on my experience talking to SoapUI users both at the conference and besides).
There are probably many reasons for its initial success (apart from a cool name); it is based on actual API usage, has a tooling ecosystem, prefers JSON and the Swagger-UI just looks great. WADL on the other hand is "just a spec", sounds suspiciously like WSDL and lacks the "underground appeal" of the Swagger community. Hats off to the Reverb team – hopefully they can govern and evolve Swagger in line with trends in the API community.
Academically, I find it interesting that a metadata format catches on at all in the REST community; much of the initial driver behind REST was to move away from metadata and specifications, and while the more biblical REST crowd talks about hypermedia APIs as a means to avoid metadata and tight coupling between client and API - the pragmatic users seems to realize the benefits of metadata in an enterprise setting (more on that below). In the end, I think whatever the API community finds best solves their problems to "get the job done" will prevail.
The religion of REST - and beyond
REST has been around for a while now - the original dissertation by Roy Fielding was published in 2001 - but it didn't really catch on until developers got fed up with the proliferation of WS standards and needed a much simpler way to consume data in the client AJAX applications around 2007-2008. Recent developments within the core REST community have me worried though; talking about "REST maturity levels" and "real REST" while quoting Mr. Fielding’s dissertation as their holy parchment gives at least me a bitter aftertaste; many of the current REST adoptions and APIs are perfectly fine and provide excellent value to their users even if they don't follow HATEOAS principles or use something like HAL to expose hyperlinks. If you're providing APIs I suggest you approach these with a grain of salt, the main goal of your API is to swoon its users, not follow design principles (although these could of course complement each other).
Back to the conference; while there was a lot of talk about the promise and implementation of hypermedia APIs and HATEOAS principles, the Netflix story told by Daniel Jacobson took things to the next level; REST wasn't a good fit for them as it put too much overhead on their client applications (tailored to 800 different clients!) which assembled their pages from a multitude of REST APIs. Their solution was to create an "orchestration layer" on the backend that assembled data from the internal APIs into what they called an "experience API". This was consumed by the device and exposed data selected specifically for that user – and as this API didn't follow any REST principles it doesn't qualify as such - it's just an API that works.
Incidentally - if you are old enough to remember (like I am) - this is similar to the move from RPC style web services to document style that happened around 10 years ago; instead of making multiple smaller calls to assemble a final result, the actual orchestration logic of all those pieces was meant to be done in one go on the server and returned in one document.
The Enterprise strikes back
So this is an interesting (but not totally unexpected) development; first, the coder community got tired of enterprise madness and SOAP and adopted REST as a means to actually deliver something of value within a reasonable time-frame. The enterprise SOA shops chugged along with their SOAP-based SOA projects, but eventually they started to realize that APIs are actually good for them too. This was not just from a technical point of view, but even more as a business enabler - allowing to bring their products to a whole new group of consumers (via APIs). Unfortunately though, the REST-based API community lacks solutions for some key requirements for many enterprises;
- Security; transport-level security provided by SSL is far from enough for health care, banking, etc - how does REST support persistent signatures and encryption!?
- Governance and Policies; how can enterprise APIs be governed through their entire lifecycle? Laura Merling from AT&T gave a great talk on how they are creating APIs with governance in place, and Lorinda Brandon wrote a great piece on the subject, check it out: Governance vs Innovation
- Transactions and Reliable Messaging; is HTTP good enough for messaging requirements that are beyond request/response? What alternatives are there?
Many of the talks at the conference highlighted the need for solutions to these problems - and I'm sure they can be solved, I'm just hoping that we in 3 years’ time won't have the same WS-(death star) mess that the SOAP community got into when the major vendors initially tried to solve these problems on their own, and then got together in extremely sluggish committees to try to unite the standard into a common one.
SoapUI does REST damnit!!
I guess this is a little off-topic but I'll take the opportunity; several people I talked to at the conference regarding testing of their APIs with SoapUI squarely countered with "we don't do SOAP". <rant>This is so frustrating! SoapUI has had extensive REST support since version 2.5 released in 2008; resources, HTTP Verbs, representations, parameters, URL-templates, JSON, XML, content-negotiation, security, you name it. You could easily set it up to test true hypermedia APIs and now there is even a swagger plugin that allows you to import swagger definitions, and given all its other testing features (and that it's actually free) it should definitely be part of an API testing strategy </rant>.
Thank you!
I’ll end with a huge thanks to all at the conference for their presence and passion, and an extended thanks to Kin Lane for his insightful and extremely knowledgeable apievangelist.com blog and his commitment to the API movement. Hope to see you all at the next conference – please share your thoughts on the above and the conference in whatever medium you find appropriate.
/Ole
@olensmar
