Decentralization, query APIs, and other myths

Web APIs provide access to
remote data or functionality.

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

SPARQL & GraphQL share a common trait:
they are both a language and an API.

GraphQL queries only have meaning
with respect to one source.

# List 10 people and their names
{
  person(first:10) {
    name
  }
}

GraphQL queries only have meaning
with respect to one source.

# List 10 people and their names
{
  users(first:10) {
    fullName
  }
}

GraphQL queries only have meaning
with respect to one source.

# List 10 people and their names
{
  friends(first:10) {
    displayName
  }
}

SPARQL queries have universal meaning
across all possible sources.

PREFIX dbo:  <http://dbpedia.org/ontology/>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>

# List 10 people and their names
SELECT * {
  ?person a dbo:Person;
          rdfs:label ?name.
}
LIMIT 10

Common misconceptions prevent us from
designing effective knowledge graph APIs.

1. Client abstractions require server abstractions.
2. Querying requires dedicated query interfaces.
3. One universal API can satisfy all use cases.

Client abstractions are not limited
to server-side abstractions.

• We saw that GraphQL means actually 2 things:
  1. a read/write query language
  2. a Web API for such queries
• Apps can be written using GraphQL
  without the server offering a GraphQL API.
• Client libraries can provide GraphQL queries
  over non-GraphQL Web APIs.

The label query API is meaningless:
every API offers some kind of query.

• Which API is a query API?
  1. /orders?id=5787
  2. /graphql?query={order(id:5787){product}}
• Every API enables filtered data access.
  • The difference is the granularity.
• Client libraries can bridge the difference.
  • Execute queries over less expressive APIs.

No single universal Web API exists
to satisfy all use cases.

• The more expressive the query language,
  the more client-specific requests can be.
• Web API design involves trade-offs.
  • Low expressivity leads to higher numbers of requests.
  • High expressivity leads to higher per-request cost.
• Observations for single Web APIs
  don’t always generalize to multiple APIs.
  • Cross-API queries are fundamentally different.

On the decentralized Web of the future,
every person has their own data pod.

• Web 1.0 is a decentralized document space.
  • Documents link to other documents.
• Solid brings Web standards for personal data pods.
  • People store their data behind access control.
  • Linked Data lets any piece of data to connect to any other.
• Multiple pods form a decentralized knowledge graph.
  • private and public parts
  • too large for any single system

Data created by or about a person will be
stored in their personal knowledge graph.

Apps over decentralized knowledge graphs
need to blend data from many sources.

A person can grant apps and people access
to very specific parts of their data.

Separating app and storage competition
creates better offerings for all parties.

By abandoning data harvesting,
we restore permissionless innovation.

Decentralized apps require query:
read/write access to a knowledge graph.

Too big and complex for any single app,
the full graph is emulated via small parts.

Access to single-source knowledge parts
can be provided through a Web API.

Document-oriented Web APIs pretend
the graph is structured across documents.

Query-oriented Web APIs combine data
of many documents of a document API.

Let’s examine the consequences of
decentralizing the knowledge graph.

Every source exposes its part of the graph
through a Linked Data Web API.

Several different Linked Data APIs exist,
each with vastly different characteristics.

Each source can expose its same graph
through multiple different Web APIs.

No single query-oriented API can help us,
since there is no single server to attach to.

The app can still be written using queries:
a library translates into HTTP requests.

Query is crucial to app sustainability since
it allows apps to make fewer assumptions.

• Apps without query bind to specific Web APIs
  rather than their underlying knowledge graphs.
  • They hardcode assumptions of where data is located
    and how any specific API structures that data.
• Query can create a sustainable contract between
  the app and the decentralized knowledge graph.
  • Bind to the data, not to a transport channel.

Moving to query means transitioning
from API integration to data integration.

• Current multi-source Web apps depend
  on hardcoding Web API integrations.
  • Extensive client-side API tooling is available to do so.
• The central assumption in the transition is that
  data integration is easier to solve sustainably.
• However, this means we need to invest
  in client-side data integration tooling.

Once we figure out the right core APIs,
we can build auxiliary APIs for use cases.

• The duty of the source is to securely expose data
  for repurposing in different contexts.
• More specific APIs can satisfy many different uses.
  • autocompletion
  • indexing
  • history
  • …
• Dedicated re-API providers build on top of core APIs.
  • API as a service
  • dockerized & reusable

Web APIs are a means to an end: we need
client-side knowledge graph tooling.

1. Client and API abstractions can differ.
   • Reusable client libraries separate the what from the how.
2. Every Web API is a query API.
   • Every Web client is a query client.
     (whether you realize it or not)
3. No single Web API is the final answer.
   • Design APIs as part of an ecosystem:
     how can APIs help—rather than replace—intelligent clients?