Carnets de bord

We will showcase Canappi during an AT&T Webinar on "Building Multi-Platform Native Applications" on Wednesday 9/15.

Canappi is a Mobile Application Development Platform that generates iOS or Android code from a DSL. It also generates back-end services (MySQL/PHP and WSO2 Stratos Data Services).

Please register here to view the webinar.

Since 2007, the industry was told by a handful of people that the "Web" could teach us everything about distributed computing, and that everything we had done before was simply wrong. Four years later, we can only see that the emperor is completely naked (what else could we expect?).

REST was designed with an end-user in mind, operating a user agent: the browser (I know Roy is going to get mad if he reads this). Everything that has been written to apply REST principles to a software agent-to-server scenario is simply wrong. To quote Roy himself:

A REST API should be entered with no prior knowledge beyond the initial URI (bookmark) and set of standardized media types that are appropriate for the intended audience (i.e., expected to be understood by any client that might use the API).

A REST API should never have “typed” resources that are significant to the client. ... The only types that are significant to a client are the current representation’s media type and standardized relation names.

A REST API must not define fixed resource names or hierarchies (an obvious coupling of client and server). Servers must have the freedom to control their own namespace.

How many Web APIs are actually designed that way? It is time to move on from all this mind bending serendipitous complexity that brings absolutely nothing, except more lost productivity by forcing to everyone to hand code everything we got for free in previous distributed computing paradigms.

So I encourage everyone to unREST with pride. No offense to Roy, REST is brilliant. It is just not applicable to the problem at hand and we should give him some REST in return, for all that he has given to us. It's cool to be RESTless. Let's not waste any more time. 

So what does it mean to unREST?

a) Define a uniform interface that suits your domain

There are many uniform interfaces to choose from: Send/Receive is one, GET/PUT/POST/DELETE is the "REST" one, CRUD has been used for 30 years world widely, ...

Don't be shy, forget the 4 little HTTP verbs, you can even define your own: Query/Do/Notify/Synchronize is a perfectly good one. It means that all methods in your Web API will be of type query, action, notification or sync request.

One could even imagine a 3-legged uniform interface, well suited to support modern converged / composite applications.

In fact, REST's so-called "uniform interface" is quite broken outside of the Web as some queries must be implemented with a POST and lots of people struggle to use PUT, POST and DELETE meaningfully. I have seen a standard using DELETE to implement the "cancel" payment operation. (I bet that's what some would like to do with their CDS transactions... )

A uniform interface is essential to a healthy API, pick one that fits your domain and stick to it. Let your infrastructure know about it from a security , scalability ... perspective.

b) Specify messages

when two agents communicate, they exchange messages. Duh? These messages rely on a shared understanding of some sort be it a standard type or semantic. Define your API messages loud an clear. This is a major step in becoming unREST.  The syntax of your message doesn't matter, who cares about XML, JSON, Protocol Buffers? What is essential is that your syntax must be extensible. This is what allows forward versioning.

Explicit message definitions which can be explicitely versioned is essential to a healthy API definition. Message Extensibility is the property that makes distributed computing work.

c) Specify contracts with a clear versioning strategy

There has been many "IDLs" defined over the years, few were truly message based. Think of a relationship between software agents as forming a machine readable "Contract" that defines the rules upon which messages are exchanged between them. A contract is something you break only when you have no other choice. A Contract is most often bi-directional and asynchronous (anyone is receiving any notification on their phone?). Thinking of every relationship as being synchronous and of type client/server, is pure nonsense. Convincing people that they could do without a contract, just with some "human readable documentation" (HRD) is also pure nonsense. How many millions of hours have been wasted worldwide the day we decided to drop WSDL for "HRDs". A uniform interface is not enough to form a contract, it is only the substrate on which a contract is defined. That contract is not uniform, by any stretch of imagination.

Machine readable contracts are the foundation on which to build a healthy ecosystem of Web API consumers. Versioning is essential to evolution and reuse, and hence a healthy API.

Please note that, reuse, in distributed computing, happens the other way around when compared to traditional software engineering. It is the old "clients" of a Web API that "reuse" the new versions of a service (without breaking). Who would expect that anyone could design an API that 3 years down the line would be "reusable" by any 3rd party consumer? It is far more valuable to enable existing client to "reuse" the new features of your API, at their pace, without breaking them, for every tweak you make into your message formats.

That's it, that's all you need to create a successful API nothing else, nothing more. Sure, it would be great if we converge on a handful of uniform interfaces and versionable message /contract specifications. I am not sure we can find "the one" that works for everyone.

I have participated in crafting web-based protocols for most of the last 12 years, starting with ebXML in 1999. The big difference between today and then, is that we have thousands of openly available data points teaching us, we, the "standard" guys, how people actually create APIs, for what purpose. Maybe for once, they could teach us a thing or two. That would avoid picking just a couple of use cases convenient to a vendor's product and forcing the REST of the world fit under that petty umbrella.

You are now free to unREST and laugh quietly at anyone who asks you to marvel at an HTTP header, a "link", use a 7 letter acronym, or tells you with the authority of a story teller that you don't get it. REST was just a (bad) dream, unREST is what you want to do.

I will be the host of an Entrepreneur's Event on June 30th at ThinkSpace in Redmond.  I will be showing Canappi, but more importantly, I will be also talking about building successful mobile apps.

The core of the presentation is on two slides (10 & 11). They focus on two important dimensions of mobile apps: the information dimension and the actions dimension (there are more such as the Converged dimension or the UX dimension).

Mobility is a major paradigm shift because mobile apps are based on a 3-legged information model: Product-Place-People, unlike the tethered Web that has no actionable location information. Amazon's business model, for instance, relies solely on linking products to people and I would not be surprised if a startup coming out of nowhere disrupts Amazon's eCommerce franchise.

Why? because location is not just about finding disruptive way to link products and people, it is also weaving  time (i.e. events) into the business model and, most importantly, it makes the world "actionable" (taking actions at a distance doesn't always work well...).

This new relationship between people and products (via places, events and action) gives the opportunity to create a virtuous circle (slide 11): people, places and events enable advanced advertising/offers models and as people take actions on goods, services, media, knowledge ... (such as purchase, consume, invoke, favor, link, collect ...) it gives the ability to capture favorites and historical data (which would be impossible to tie to a location or event without a mobile device) thereby providing a formidable feedback loop to advertising models and offers in very innovative ways.

Hope you like the presentation and join us in Redmond if you can !

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.

I attended a presentation last night by Tim Bray on the Android Ecosystem. Here are my notes, he provided a great perspectie on defining a business model for your mobile app.