Web APIs for decentralized knowledge graphs

Web APIs provide access
to remote functionality.

1. action APIs
   • RPC
   • SOAP
   • XML
   • …
2. document APIs
   • REST APIs
   • LDP
   • …
3. graph APIs
   • GraphQL
   • SPARQL
   • …

Graph APIs are just a specific kind of document APIs.

There's no such thing as a query API.
All Web APIs provide some kind of queries.

• Solid apps want to query:
  gather data from multiple documents and pods.
• We tend to make two wrong assumptions:
  1. Client-side query necessitates server-side query.
  2. Servers need dedicated query APIs.
• Web APIs for decentralized ecosystems
  require a very different design mindset.

Solid applications need, in some way,
read/write access to a knowledge graph.

The graph is too big for any single place,
so apps reconstruct the whole via parts.

When knowledge fits in a single source,
we can place an API in front of it.

Abstract knowledge needs to be exposed
through concrete documents/resources.

A GraphQL API combines data from across
multiple resources of the “main” API.

Let's revisit the story for cases where
knowledge cannot fit in one place.

Each data pod exposes its part
as RDF through a Web API.

Different APIs for RDF
have different characteristics.

It quickly becomes unfeasible for apps
to deal with all possible API combinations.

A GraphQL Web API cannot help us,
since there's no server to attach it to.

The app can still be written with GraphQL:
a library translates it into HTTP requests.

Solid has kickstarted the transition
from API integration to data integration.

• Solid app developers face challenges…
  …but API problems are not among those!
• The way we write apps can be independent
  of the Web APIs offered by servers.
  • Clients can have their own abstractions.
• Let's invest in reusable client development patterns.