Warning:
This wiki has been archived and is now read-only.

URIs versus APIs

From Data on the Web Best Practices
(Redirected from URI's versus API's)
Jump to: navigation, search

Introduction

This page summarizes the questions, arguments and links cited by the participants of the group in a discussion, "APIs to work with data on the web", about the advantages and disadvantages of using APIs to access Data on the Web.

The challenges related to this discussion are listed in General Challenges - Use Cases DWBP

A first conclusion of this discussion is that it could be worthwhile to write recommendations that are meaningful for anyone in any way they access Data on the Web, that could mean:

  • Accessing Data via URI
  • Accessing Data via URIs as parameters within APIs
  • Accessing Data via APIs when no URIs are present
  • Accessing Data by means other than API or URI

Advantages and Trade-offs of using APIs to Access Open Data

Questions

  • Are APIs within scope for a Data on the Web BP WG?
  • Do we need to recommend how applications interface with Data in order to create Best Practices in how Data is published, described, qualified, quantified, and compared?
  • Are details on how to publish a good hypermedia API a wider issue than Data publishing?
  • Where does Data Best Practices end and Application Best Practices begin?
  • Are there performance implications in using APIs?

Arguments (URI)

  • Data access by HTTP and URI provides a common interface for humans and machines
  • A collection could be a Resource with a URI
  • It is possible to use URI to SPARQL mapping tools to access collections
  • Linked data API maps URIs to SPARQL queries
  • Direct access on a known item (the one that you have the URI for) should be by URI resolution (with content negotiation when appropriate)
  • If you want to publish "3 star data" then you MUST have a stable URI for the Dataset and SHOULD have a URI for each version of the Dataset (for archiving), as well as a "latest version" URI. Those are Best Practices to support linking and archiving of Datasets
  • If you want to publish "5 star data" then you MUST have a stable URI for everything in your Dataset AND the Dataset, or re-use existing URIs
  • Publishing Linked Data is a Best Practice, and the use of URIs follows from that (you can't do Linked Data otherwise)

Arguments (API)

  • APIs are one of the simplest ways to access and to distribute Data across the web
  • APIs can be seen as a basic set of functionalities provided to developers to access Data and metadata
  • Nowadays is very common to develop mashups using a set of APIs to compose a final result from different sources
  • Publishers may want or need to support multiple ways to access the same Dataset
  • Support the widest possible set of consumer needs
  • Support everything from local bulk indexing, through to simple online browsing of the data
  • A SPARQL endpoint is an API
  • A User can build different collections with SPARQL queries
  • Good hypermedia based APIs will return standardized documents that describe how to interact with that interface
  • Many APIs don't return standardized documents and you have to read docs in order to understand how to interact with them

Links