0

I am building an API to connect RDF data to a React front-end.

The data is stored across several datagraphs. The API has access to all datagraphs. React will call the API to get the data, then display it to users. Most UI views will require data from several different graphs.

For example:

Datastore1_Variable1 + Datastore2_Variable3 -> UserView1 
Datastore1_Variable2 + Datastore3_Variable1 -> UserView2

It was my intention to build a service-oriented API where users call API/UserView1 to get all data required to build UserView1 in a single call.

However, I am being advised to build a seperate API per Datastore, and having React call each Datastore-API in turn. It seems to me this will require more roundtrip calls and doing complex joins at the front-end. The only reason seems to be: "this is how we've always done it".

Does a functional / efficiency reason exist why datagraphs should be exposed seperately?

Rob G
  • 123
  • 3
  • 15

1 Answers1

0

It was my intention to build a service-oriented API where users call API/UserView1 to get all data required to build UserView1 in a single call.

This is generally considered a bad way to design an API and is philosophically in opposition to principles around RDF and linked data. I know this seems counterintuitive, as the alternative is to make several API calls to fully hydrate your view. To build an API with endpoints like API/UserView1 means you've designed API that only works with your app. The two are very tightly coupled. Your API is useless outside of that one, very specific, use case. Given that you mentioned that this is an RDF API, that tells me this API needs to follow standards, be designed for maximum interoperability.

REST APIs generally model resources and collections. Resources and collections have a "stable" name (meaning the URI to fetch a certain resource) doesn't change. If you build a level-3 REST api, the resulting payload will contain links to other resources and collections that the client might be interested in.

Properly organizing your API is a worthwhile endeavor, especially if that API is to have a long and useful life. Designing a REST API properly is not dogma, the design decisions are well thought out and have real practical implications that aren't obvious right now.

Since you mentioned it's an API that serves up RDF data, my advice is to respond with JSON-LD. This follows many conventions that are familiar to web developers but includes the benefits of RDF.

If it was me, I would also consider exposing a SPARQL endpoint. Since your data is available in an RDF format, SPARQL will allow clients to ask for very specific graphs from a standard API endpoint that isn't tightly coupled to the current version of a specific app.

Code Magician
  • 23,217
  • 7
  • 60
  • 77