TL;DR: when building gateway platforms that interact between diverse third-party clients and service providers, adopt or define an open protocol/API specification; avoid imposing a proprietary scheme. Promote an open ecosystem, as ecosystems can be leveraged. 😈
Maciej Ceglowski the developer of Pinboard, a bookmarking service, has posted on a change in IFTTT’s relationship with the services they ‘support’, bringing to light an inevitable position of contention around these ‘API gateway’ platforms.
What IFTTT (a gateway or intermediary that glues together umpteen diverse provider’s independent APIs to create supplementary services) is rather short-sightedly doing is by no means the first time in this field. It may seem like it could simply be blamed on highly (or perhaps under) paid lawyers erring away from risk (hardly ideal for growing business)…
…Yet more importantly shows a distinct lack of effectively building (and maintaining) third-party developer relations (community), and the capability to arbitrate between their needs and requirements, versus those of the business (not to mention the lawyers). This is an essential role if your business is dependent upon such suppliers.
It also unearths a lack of wider vision within an ecosystem. Having built several such API gateway platforms (mostly in the photosharing field, starting client-side with PictureSync and ending with much more comprehensive server-side Pixelpipe) I only know too well the costs that constantly changing supplier APIs can inflict on a platform’s developers, yet I also completely understand the author’s position that they, a co-opted supplier/service provider, shouldn’t be forced to follow some proprietary implementation to remain compatible.
The re-emergence of this issue perhaps demonstrates that my own historic attempts to avoid this very position were just a bit ahead of the curve, yet that maybe now might be a good time time to revisit the topic.
Most such gateways have to initially work hard to develop private arrangements to gain access to provider’s APIs one by one, with the onus thus on the gateway as a consumer of those suppliers to build interconnectivity through implementations on their side. Latterly, smaller and newer provider’s want to join the party, and often what happens is that they are then required to implement a new proprietary scheme defined by the gateway, whose growth has enabled it to impose its own scheme on new participants. If providers are lucky they can use a ‘borrowed’ scheme (an API copied from another gateway or provider).
This could all be avoided.
Having seen these issues, I had started developing MediaSock and a subsequent more flexible API as open(source) specifications back round ‘05–09 that they could be adopted (and adapted) by developers of both clients (suppliers) and servers (gateways), with the intention of achieving intrinsically wider availability and support in a single common abstract scheme, as opposed to needing a separate implementation for each and every relationship. That’s not to say a single such scheme would ever work (nor be sensible) for everyone, but such a path would certainly facilitate and edify.
If only we worked together.
Next time you need to build or interact with an API, ask yourself, might a private use have public uses too? Does it share commonalities with other similar APIs? Could it become a de-facto standard (e.g. Flickr for photo sharing) and therefore drive adoption of better standards, especially if designed from the outset with that goal? Would doing so not serve the benefits of the business too?
The costs for such an approach may initially be higher, yet this is what a developer community can help with. Engage with third-party developers and they will help define, build and propagate any emergent common elements.
Certainly smaller service providers aren’t usually in a position to undertake and especially lead such developments, however gateway services are blessed with an intimate understanding of requirements, and can build upon this into a respected leadership position. This also further attracts talent, both in terms of recruitment, and also within the community.
Support the ecosystem. Everyone benefits.
These principles will be essential to the next phase of the internet, the Internet of Things, with adoption and growth at massive scale, and a truly diverse ecosystem of providers. How the hell would they all achieve anything without wide consensus?
IFTTT have such an opportunity now. Many others in similar situations probably do too. (But I stopped paying much attention to the API field ages ago.)
Flickr was an interesting case. They had the opportunity to develop an abstract specification, but the sector was small at the time. So why did the Flickr API become so ‘borrowed’ by other providers leading to an explosion of client apps? The sector saw massive growth. It started with a simple forum in which developers participated. Some clients were developed. Rather than ask those clients to change their code, as other providers emerged they borrowed Flickr’s API. With more services supporting the API, even more clients were developed, but now with the ability to specify the provider. Win! Well, except for the lack of abstraction, which is where an opportunity lay for gateways to lead and wider interconnectivity to develop.
Flickr’s API, and its little known first version, arguably also provided some origins for OAuth, a truly generic API, and thus now thousands of others enabled by it…
—
It’s probably worthwhile to quickly outline the process within such an API ecosystem scenario.
- Abstraction follows an early stage of comprehension, where several use cases are identified as overlapping and can be merged to define an abstract of their individual features.
- Genericisation is the implementation of common functionality supporting the new abstract scheme.
- Normalisation is adaptation, perhaps only for differences in language, but also for edge cases allowing deeper interactions and use, and especially for businesses specific behaviours.
The normalisation routines and logic would typically be specific to a provider’s business, however some elements may have been included in the abstraction. Sticking with photosharing as an example, agreeing that ‘title’ and ‘head’ mean the same thing but to use only ‘title’. Contrarily if no abstraction is defined the knowledge that these are equivalent allows a provider to map them in their own implementation.
Deeper normalisation, or transmogrification, is required when a behaviour that is unreconcilable through the abstraction alone is needed, such as transferring an image to a textual status update. In such a scenario the gateway provider might host the image and embed a link to it, a clearly unique functionality from the business, yet enabled by an ecosystem.
—
As an addendum, when I had been working on the Pixelpipe gateway, the opportunity was there to introduce an abstract scheme and usurp the lead taken by Flickr, unfortunately as is often the case, the business priorities changed. I latterly let the schemes I’d been working on die as I had little interest and experience in building and promoting communities (of developers) at that time, nor collaborators. Strangely I subsequently went down the path of learning more about … physical communities.
This is a path I continue to follow (with Moonlighting) even though these gateway platforms continue to fascinate me as enablers of communication and interconnectivity, not only for systems (IoT), but people and communities! It seems I may be slowly moving back towards it in my programming experiments (with Moonstalk)…
