|« A Blueprint For Building Mobile Applications that Rock !||Interesting Perspective from Tim Bray on Mobile Apps Business Models »|
Boris posted yet another article on SOAP vs REST on InfoQ yesterday. I had demonstrated last year that REST had brought nothing new. This is year it is even more crying. Nobody cares any longer about being RESTful, the industry even came up with a new term to celebrate this transition: "Web APIs". "Service" is the new "Distributed Object". I am actually ready to give $100 to the first person who proves me that there are more than %1 of Web APIs on the Programmable Web that are "RESTful" (i.e. at least 33 with the current count of 3300+). What I mean by RESTful is that 100% of the provider's Web API follows REST principles (URL path, correct use of HTTP verbs, use only HTTP verbs + nouns, HATEOAS, media types ...), you know the kind of things that the RESTafarians sold to the industry way back when in 2007. (I am dead serious, send me your list and I'll publish it and send you a check).
The problem that REST has created (that my good friend Jim Webber would simply qualify as the Same Old Atrocity) is that now any API designer gets a free license to be a distributed computing guru, artistically deciding where to put things like version and credentials, and encode actions and queries as they please amongst a wealth of headers, tokens, query parameters, bodies and what not. If you ask me, REST has produced the software industry WOrst Atrocity ever.
But, let's move on, because it actually doesn't matter: we now live in a POST REST/SOAP world. Converged (Mobile) Applications have pushed the envelope of what distributed computing should do and how it does it. Never HTTP or SOAP were really prepared for 3-legged authentication, respect privacy and support monetization at the scale of several billion API calls/month. Actually SOAP was a bit more prepared since a message could have a number of security tokens representing different principals, but who cares, we were told that HTTP was the answer, because it was "RESTful" so now we struggle with all kinds of three-legged authentication mechanisms.
A converged app is an app that is leveraging a combination of 21st century capabilities like voice, messaging, data, location, video, payments ... in a secure and privacy-friendly way. A typical converged app would be for instance an app that is able to call FourSquare Web API to get my list of friends nearby, lookup their phone numbers from a "My Contacts" API (Local or Remote), then call Yelp to find the places where we could meet or EventFul for the events we could go to and finally call Twilio's SendSMS API, and see who responds. The app collects the votes, and everyone meets at the place that has the most votes. After the party, the same app would allow me to share pictures and videos with all my (FB) friends. When using a converged app, end users don't want any API provider (and marketer) to know what they are doing, this is called privacy, something the good old Web made a business model of, on your back. Web advertising has become creepy lately because I visit sites I never visited before who advertise for products I searched on Google last week. That is really creepy, it turns me off completely.
Converged applications are changing everything because the ability to mashup APIs (and no longer just establishing a one-to-one consumer/provider relationship) becomes the most important focus of the application, in a 3 legged scenario where the user, the application and the Web API provider(s) are in a completely different relationship than the monolithic relationships we were so used to, in the mainframe, client-server and Web app days, where basically the enduser "logs in" to a monolithic app and that app only knows what the user does with it.
What's a "contract" in this new world of Converged Applications? after all the industry is only selling billions of them every year. Shouldn't we care a bit? As a starter, if you are an API provider you better get ready to manage the "apps" that consume your API and start issuing API keys. Is there a standard for that? uh? sorry, the standard bodies missed that. API keys are now the key to your endpoints. Shouldn't you also try to avoid the embarrassment of a Facebook which leaks its enduser identifiers in its API in 3-legged scenarios, seriously and totally compromising the privacy of their members. uh? is there a standard for securely and privately identifying users (and other key identifiers) across converged apps? uh? can REST do that? SOAP? wake up... guys the world if moving at lightning speed.
The old "consumer/provider" relationship established by SOAP/WSDL and later "enhanced" with HATEOAS is completely overwhelmed by this new world. Just take the simple problem of mapping data identifiers in a mashup (PK/FK). We need a new "contract" concept much more consumer centric, that helps build and maintain converged applications. At canappi, I have started to come up with such contract definition. If we wait for another year to come up with a decent Web API versioning strategy will create "for-ever" APIs or a massive break-down in all the converged apps. We also need much more sophisticated security standards, where a service provider needs to enforce that an authenticated application, used by an authenticated user does what it is supposed to do while understanding a thing or two about privacy and monetization (Converged App users vote with their wallet, not "clicks"). Finally, I contend that HTTP is completely inefficient to serve Gazillions of API calls per year and that we need a much better API protocol.
We also need standards that are (client) developer friendly not Google or Facebook friendly, that let them write apps that are (3-legged) secure, privacy-aware and monetizable (unlike HTTP or SOAP). It's already hard enough to write a mobile app, we don't need any kind of additional crap because it is convenient to X,Y or Z API provider. We are in the digital economy (if you doubt it, just check how many swords your phone carrier sold last year): we need the standards to support it. Will the industry really have the courage to take that on? will my good friends in the standard bodies, for once, try to be ahead or at the very least in line with their time? or will the RESTafarians one more time force us to hand code every f**ing API calls? I doubt we'll do the right thing, but I'd love to be wrong.
The Web, as it was designed 20+ years ago, is old, way too old to move forward in the Converged Apps world. Anyone who tries to convince you otherwise is emotionally attached to this great but rapidly aging platform.
Yeah, so this was 2 years ago. How are things looking today?