Building a more intelligent generation of clients for a decentralized Web
Ruben Verborgh is a professor of Semantic Web technology at Ghent University — imec and a research affiliate at the Decentralized Information Group at MIT. He is also a Solid Developer Advocate at Inrupt, an organization that supports Solid, an open-source project and ecosystem. Ruben Verborgh aims to build a more intelligent generation of clients for a decentralized Web at the intersection of Linked Data and hypermedia-driven Web APIs. At APIdays Paris, he talked about the impact of decentralization on APIs and clients, through Solid as a new way of thinking about data, applications and APIs.
As an introduction can you explain what Solid is?
Solid is a project initiated by Sir Tim Berners-Lee, inventor of the World Wide Web, started at MIT. Solid aims to radically change the way Web applications work today, resulting in a more healthy competition between apps as well as improved privacy. Solid is a proposed set of conventions and tools for building decentralized social applications based on Linked Data principles. Solid is modular and extensible, and it relies as much as possible on existing W3C standards and protocols.
What is the philosophy behind Solid?
Companies today are competing based on their ownership of data, not so much on their innovation. As a result, people are losing control of their data and companies are engaged in harder competition between themselves and against giants like Facebook or Google who harvest much more data. In this context, Solid is a new way of thinking about data, applications and APIs.
Developers tend to think about collecting data first, while Solid aims at decoupling the data from the application. As a result, since the data and the app are stored independently people will be able to move their data and switch services more easily.
What is the current adoption of Solid in the developer’s community?
For Solid to be more widely adopted in the developer community, we need developers to subscribe to this philosophy and switch from “harvesting as much data as possible” to “asking permission to existing data”. We are still also lacking a full ecosystem where people decide to share generic APIs and benefit from community reuse of APIs. What we see a lot on the market is a multiplication of APIs or the wide usage of APIs from Facebook, Twitter, Instagram that are very different in their philosophy of data usage.
At this stage, the culture of API reuse is not widely shared, and we all collectively still must learn lessons from API design.
What is really at stakes with Solid?
What is really at stakes with Solid is that app creators and developers have the choice to develop APIs or reuse existing APIs, that they have the choice to store data independently of applications, and that people have the choice to decide what data they give for what usages.
Interoperability is an enabler for that choice.
In fact, Solid goes back to the original vision of the web with the notion of universality. That’s why websites created in the 90’s can still be accessed on our phones today. Anything should work with anything. Today most of the web’s interactions are through devices and APIs. Websites were designed for people, and APIs for machines. But people are developing APIs that must be hardcoded to be integrated. If we built websites that way, each phone would only be compatible with a small set of websites. We are missing out on the development ecosystem.
What could be achieved with an ecosystem vision about APIs?
This ecosystem vision is also connected to a long-term vision about APIs. There is still short-term thinking about APIs, from companies and developers who don’t think about what will happen to their APIs in 5 years. Priding ourselves on the fact that we have thousands of different APIs is also missing out on what could really be achieved as an ecosystem. Imagine if for the web we had developed thousands of different HTML variations. Of course, companies and developers are proud of the diversity of their applications, but this diversity prevents the understanding of APIs.
Donald Knuth said that in programming “premature optimisation is the root of all evil”. He meant that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times. Crafting an API is not always positive in the long term, recycling an existing API can be the best move.
In fact, we have been talking about APIs for years, but we still don’t talk much about reuse. We keep choosing the “big APIs” and as a result Facebook has peoples’ and developers’ data. But what if other APIs were compatible? If you think about compatibility instead of thinking about specific APIs, we collectively as an ecosystem can have much more.
What are misconceptions that people have about APIs?
This Solid philosophy and the broad API idea is not a message solely for the open source community. In fact, APIs are touchpoints in an information system, their implementation can be open or closed. APIs need to be understood as the product of an ecosystem, so what is important is not what is behind the API (its infrastructure, its implementation) but the API itself and its different reuses on different platforms. The LDP API (Linked Data Platform) is an interesting example of this reusable API philosophy, as it is implemented by many different parties in different ways.
Reusability is at the basis of Solid, so looking at API statistics in term of API usages is also flawed. We should rather look at the API reuse, meaning the number of applications using that API and thus the compatibility of the API with many environments. API reuse is based on compatibility and it is what can make us all collectively win.
Written by Séverine Godet
Want to contribute articles to APIdays? Please fill out this short (2min) form
